From cabo@tzi.org Sat Feb 1 02:04:53 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34AB1ACCE2 for ; Sat, 1 Feb 2014 02:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8GMENxka2pj for ; Sat, 1 Feb 2014 02:04:53 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B7E991A04CD for ; Sat, 1 Feb 2014 02:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s11A4dq3028119 for ; Sat, 1 Feb 2014 11:04:40 +0100 (CET) Received: from [192.168.217.105] (p54892C3C.dip0.t-ipconnect.de [84.137.44.60]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6ADF557F; Sat, 1 Feb 2014 11:04:39 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Reducing the battery impact of ND From: Carsten Bormann In-Reply-To: <52ECA6EE.1080201@acm.org> Date: Sat, 1 Feb 2014 11:04:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8A362DBA-6CBE-4DAA-A132-5E9647A37BBD@tzi.org> References: <52D96663.6060005@sonic.net> <52DA0ABA.8030903@acm.org> <52E03BB4.8040309@acm.org> <52E0423A.5070906@acm.org> <01DC3532-C73A-4644-A323-04BE6231AADA@employees.org> <52E9EF2D.9050402@acm.org> <2CFF305E-DE44-4D57-82D3-241196D94610@employees.org> <52ECA6EE.1080201@acm.org> To: 6man WG X-Mailer: Apple Mail (2.1827) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 10:04:54 -0000 On 01 Feb 2014, at 08:49, Erik Nordmark wrote: >> ... and can someone please remind me what exactly was wrong with ARP? = Other than the fact that v4 uses it?! What Erik said, plus maybe this reminder: When ARP was invented more than 30 years ago, Ethernet networks were run = on the assumption that everyone on them could be trusted, both from a = security and from an implementation bugs perspective. (Those yellow-cable networks were so fragile... Let=92s not digress.) To make ARP actually work in less peaceful environments, there is = usually significant hackery deployed at layer 2 (in Ethernet switches = and WiFi base stations/controllers). With all that hackery in place, it = may *seem* as if ARP works, but it is really the combination of the ARP = implementation in the IP nodes and the magic in the switches that makes = this so. ND inherited most of this situation, except that the hackery wasn=92t = deployed yet. That=92s why you hear so much about ND being =93insecure=94= , =93not deployable=94 =97 ND really is much better than ARP, it just = had to wait for the hacks to catch up. The directed multicast of ND (as = opposed to ARP=92s broadcast) only makes a difference where L2 actually = implements that directionality; more hackery. (The irony is that MLD = now becomes an address registration protocol that is needed to make the = illusion of "no registration" work at the ND level, but I digress = again.) So the reality today is that we have this fragile combination of the = documented protocols and the switch vendor magic that makes it all work. = Of course, the switch vendors don=92t complain; it creates an = opportunity for market differentiation. Now, for 6LoWPAN, we had to build something that relies much less on = multicast. That became 6LoWPAN-ND, RFC 6775. Having built this fine = hammer, of course other nails sprang to mind. The above situation looks = like a fine nail to me (except that legacy compatibility makes things so = much more complex). That=92s maybe the explanation why this discussion = didn=92t start with documenting the well-known problems, but with = looking at one specific solution, and how it could be made to work with = legacy. But I agree documenting the problem would be a worthwhile = exercise, if it is not used as an excuse to stop looking for solutions. Clearly, efficient-ND will work best if it doesn=92t require a new layer = of L2 hackery, and if it cooperates reasonable with (or works around) = the existing, deployed hackery. This is more work to make sure given = that this hackery is only partially documented. So that is maybe = another reason to work on documenting ARP/ND=92s problems and the = existing magic. Gr=FC=DFe, Carsten From pthubert@cisco.com Sat Feb 1 03:02:40 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29251ACCEB for ; Sat, 1 Feb 2014 03:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yhjcveWcCsS for ; Sat, 1 Feb 2014 03:02:38 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id AD4611ACCF8 for ; Sat, 1 Feb 2014 03:02:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3996; q=dns/txt; s=iport; t=1391252555; x=1392462155; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=aaLKI/byeGvYr2KgRgVp085Z+C2fGjU5Nld/llPtHiE=; b=AQA0L8QJNcC0gWHAWWBRd9B1aRf3Scw8Gos2naEPVj074sE4JGyCnbV6 UuAvFvMaF3qBpixFxrFmcelfQzV85QCc7Ipoeedq/Gm0+ukc/cd5pNlty OSC0ckH1VWVfXl5kmPgjNYF27v13IVWGTxaaJX9Kc9Ofvs/h2wFp9bAQx U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAAnT7FKtJV2d/2dsb2JhbABZgww4vjeBBRZ0giUBAQEDAQEBAWsCCQULAgEIDgouJwslAgQOBRuHYggNzSETBI4hNTMHgySBFASYKpIhgy0 X-IronPort-AV: E=Sophos;i="4.95,760,1384300800"; d="scan'208";a="17191491" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 01 Feb 2014 11:02:34 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s11B2YKQ024021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 1 Feb 2014 11:02:34 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.119]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Sat, 1 Feb 2014 05:02:33 -0600 From: "Pascal Thubert (pthubert)" To: Carsten Bormann Subject: Re: Reducing the battery impact of ND Thread-Topic: Reducing the battery impact of ND Thread-Index: AQHPHzUTiMCxaPXhG0aRhxb2a+DuMZqgO80n Date: Sat, 1 Feb 2014 11:02:33 +0000 Message-ID: <1F38DE17-84B2-4151-B4AF-05B5BE76EDCE@cisco.com> References: <52D96663.6060005@sonic.net> <52DA0ABA.8030903@acm.org> <52E03BB4.8040309@acm.org> <52E0423A.5070906@acm.org> <01DC3532-C73A-4644-A323-04BE6231AADA@employees.org> <52E9EF2D.9050402@acm.org> <2CFF305E-DE44-4D57-82D3-241196D94610@employees.org> <52ECA6EE.1080201@acm.org>,<8A362DBA-6CBE-4DAA-A132-5E9647A37BBD@tzi.org> In-Reply-To: <8A362DBA-6CBE-4DAA-A132-5E9647A37BBD@tzi.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Watteyne , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 11:02:41 -0000 +1, Direct from an implementor of the hackery in question in widely distrib= uted switches and wireless controllers. Our first generation was really about protecting against rogues (SAVI, RA G= UARD). Interestingly, our second generation was focussed on multicast control to p= rotect the wireless medium (ND Suppression including RA throttling and ND p= roxy) to address customers and product management requests for the wifi mar= ket. Based on that support, I have developped a prototype backbone router that l= earns southwards from 6LoWPAN ND registration and proxies northwards classi= cal ND. 6TiSCH has planned a plugfest during the IETF and I hope we=B4ll be able to= demo this fonctionality at that time with real ipv6 motes. Cheers, Pascal > Le 1 f=E9vr. 2014 =E0 11:05, "Carsten Bormann" a =E9crit : >=20 > On 01 Feb 2014, at 08:49, Erik Nordmark wrote: >=20 >>> ... and can someone please remind me what exactly was wrong with ARP? O= ther than the fact that v4 uses it?! >=20 > What Erik said, plus maybe this reminder: >=20 > When ARP was invented more than 30 years ago, Ethernet networks were run = on the assumption that everyone on them could be trusted, both from a secur= ity and from an implementation bugs perspective. > (Those yellow-cable networks were so fragile... Let=92s not digress.) >=20 > To make ARP actually work in less peaceful environments, there is usually= significant hackery deployed at layer 2 (in Ethernet switches and WiFi bas= e stations/controllers). With all that hackery in place, it may *seem* as = if ARP works, but it is really the combination of the ARP implementation in= the IP nodes and the magic in the switches that makes this so. >=20 > ND inherited most of this situation, except that the hackery wasn=92t dep= loyed yet. That=92s why you hear so much about ND being =93insecure=94, = =93not deployable=94 =97 ND really is much better than ARP, it just had to = wait for the hacks to catch up. The directed multicast of ND (as opposed t= o ARP=92s broadcast) only makes a difference where L2 actually implements t= hat directionality; more hackery. (The irony is that MLD now becomes an ad= dress registration protocol that is needed to make the illusion of "no regi= stration" work at the ND level, but I digress again.) >=20 > So the reality today is that we have this fragile combination of the docu= mented protocols and the switch vendor magic that makes it all work. Of co= urse, the switch vendors don=92t complain; it creates an opportunity for ma= rket differentiation. >=20 > Now, for 6LoWPAN, we had to build something that relies much less on mult= icast. That became 6LoWPAN-ND, RFC 6775. Having built this fine hammer, o= f course other nails sprang to mind. The above situation looks like a fine= nail to me (except that legacy compatibility makes things so much more com= plex). That=92s maybe the explanation why this discussion didn=92t start w= ith documenting the well-known problems, but with looking at one specific s= olution, and how it could be made to work with legacy. But I agree documen= ting the problem would be a worthwhile exercise, if it is not used as an ex= cuse to stop looking for solutions. >=20 > Clearly, efficient-ND will work best if it doesn=92t require a new layer = of L2 hackery, and if it cooperates reasonable with (or works around) the e= xisting, deployed hackery. This is more work to make sure given that this = hackery is only partially documented. So that is maybe another reason to w= ork on documenting ARP/ND=92s problems and the existing magic. >=20 > Gr=FC=DFe, Carsten >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From shemant@cisco.com Sun Feb 2 06:44:32 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847621A00E0 for ; Sun, 2 Feb 2014 06:44:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lrocqP95hLH for ; Sun, 2 Feb 2014 06:44:31 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D9FC21A00E2 for ; Sun, 2 Feb 2014 06:44:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2630; q=dns/txt; s=iport; t=1391352267; x=1392561867; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WwR+aP/UZ0Vs2tKbviY98ltTYSX2FAMGvhdAo/AJiuo=; b=Al9uxTMdHh2s7pNQPsRmI34/+UYys7kQG11zTZ0RUudXZXQi8Ggo8H1c VD2QiGU18RYL79c2NW2esizP2bgzOUsvIe/+NHyJ9lojRCGrYEltjhH23 SznauvB6oUyrafeh6K2Wfc5lIegGe6sPwxVpYEIVwhCQYFtfkRDEe6sBp 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAEZZ7lKtJXG+/2dsb2JhbABYgww4V71hgQEWdIIlAQEBBCcTPwwEAgEIEQQBAQsUCQcyFAkIAgQBDQUIDIdxDalyog8XjiEQJzEHBoMegRQBA6pLgy2BaEI X-IronPort-AV: E=Sophos;i="4.95,766,1384300800"; d="scan'208";a="301309663" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 02 Feb 2014 14:44:26 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s12EiQQ1016633 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 2 Feb 2014 14:44:26 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.70]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Sun, 2 Feb 2014 08:44:25 -0600 From: "Hemant Singh (shemant)" To: Erik Nordmark , Warren Kumari , "Ole Troan" Subject: RE: Reducing the battery impact of ND Thread-Topic: Reducing the battery impact of ND Thread-Index: AQHPF8uCi/rGSSFcckK5k2X6Rw6QUJqdO7yAgABDuoCAAA28gIAC6/EAgAGb2IA= Date: Sun, 2 Feb 2014 14:44:25 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89115D182D@xmb-rcd-x06.cisco.com> References: <52D96663.6060005@sonic.net> <52DA0ABA.8030903@acm.org> <52E03BB4.8040309@acm.org> <52E0423A.5070906@acm.org> <01DC3532-C73A-4644-A323-04BE6231AADA@employees.org> <52E9EF2D.9050402@acm.org> <2CFF305E-DE44-4D57-82D3-241196D94610@employees.org> <52ECA6EE.1080201@acm.org> In-Reply-To: <52ECA6EE.1080201@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.172] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG , Andrew Yourtchenko X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 14:44:32 -0000 Folks, We have ended up comparing IPv6 ND and ARP. A few more issues. Note ND N= UD is getting closer to ARP behavior with rfc7048. Also, ARP was great in= one regard by using a different ethertype than the IPv4 ethertype. IPv6 N= D should borrow the same concept and use a different ethertype for IPv6 ND = control since IPv6 ND NUD uses unicast messages which are difficult to snif= f. High end routers that are forwarding packets at several hundred Gbps w= ould filter ND control easily, subscriber edge routers that support DAD Pr= oxy, or machines that support an ND Proxy would benefit from a new ethertyp= e for IPv6 ND. =20 If the community is interested in supporting a new ethertype for IPv6 ND, p= lease let me know. I would expedite an I-D from Cisco who has IPR related = to the new ethertype. See http://www.google.com/patents/US8102854 Hemant -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Erik Nordmark Sent: Saturday, February 01, 2014 2:49 AM To: Warren Kumari; Ole Troan Cc: 6man Chairs; Erik Nordmark; Andrew Yourtchenko; 6man WG Subject: Re: Reducing the battery impact of ND Warren, Are you asking about the specifics of this topic (how to save on battery an= d multicast), or a general question on the original motivation for ND? On the more general question: ARP didn't have any of - NUD (called dead gateway detection back in the days), - prefix discovery, - router discovery, - address allocation (bootp -> dhcp was brand new and unproven at the time) (I might be missing something.) ARP only had the address resolution functionality. There was a perceived need to be able to handle multiple prefixes and addre= sses per interface, and a way to renumber those addresses. The nascent DHCP= v4 wasn't architected to support multiple addresses. We had RFC 1256 (ICMP router discovery) as a protocol with very limited dep= loyment for one of the above pieces. We wanted a more extensible packet format than ARP and reusing IP/ICMP seem= ed like a good idea since it could enable reusing IP security mechanisms. (= Much later when SeND was designed it turned out reusing IPsec was hard - bu= t the more extensible packet format was key.) For the more general question of battery and multicast/broadcast, folks see= m to agree that current ND (with address resolution spread across a large n= umber of multicast addresses) is more scalable than ARP's broadcast. (But o= n WiFI where broad/multicast is lower bandwidth and less reliable they have= the same issue.) Erik From l.wood@surrey.ac.uk Tue Jan 21 09:45:08 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363881A01B4; Tue, 21 Jan 2014 09:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTOrdaOmjAJd; Tue, 21 Jan 2014 09:45:05 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.151]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0481A01B1; Tue, 21 Jan 2014 09:45:05 -0800 (PST) Received: from [195.245.231.67:51499] by server-15.bemta-5.messagelabs.com id 45/9A-08490-022BED25; Tue, 21 Jan 2014 17:45:04 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-5.tower-82.messagelabs.com!1390326303!27339282!1 X-Originating-IP: [131.227.200.43] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24816 invoked from network); 21 Jan 2014 17:45:04 -0000 Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-5.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 21 Jan 2014 17:45:04 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Tue, 21 Jan 2014 17:45:03 +0000 From: To: , , Date: Tue, 21 Jan 2014 17:40:03 +0000 Subject: RE: Stephen Farrell's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS and COMMENT) Thread-Topic: Stephen Farrell's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS and COMMENT) Thread-Index: Ac8Wxw54TzR8vcWJRCCmlfmuiUhlwwACMJqN Message-ID: <290E20B455C66743BE178C5C84F1240847E63346D8@EXMB01CMS.surrey.ac.uk> References: <20140121155253.23475.70004.idtracker@ietfa.amsl.com>, <52DE9E63.5050404@si6networks.com> In-Reply-To: <52DE9E63.5050404@si6networks.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 03 Feb 2014 08:34:38 -0800 Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, draft-ietf-6man-stable-privacy-addresses@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 17:45:08 -0000 See (and cite) RFC6151 section 2. MD5 is still useful as a checksum for really big files, where you're lookin= g for accidental differences introduced by errors, and MD5's efficiency of = computation is a win. But that says nothing about being tamper-proof. Think= of it as a big CRC32, and CRC32 is not seen as having security properties. In an explicit crypto hash context where you're relying on the security pro= perties, don't use MD5. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Fernando Gont [fgont@si6networks.com] Sent: 21 January 2014 16:20 To: Stephen Farrell; The IESG Cc: 6man-chairs@tools.ietf.org; draft-ietf-6man-stable-privacy-addresses@to= ols.ietf.org; ipv6@ietf.org; Wood L Dr (Electronic Eng) Subject: Re: Stephen Farrell's Discuss on draft-ietf-6man-stable-privacy-ad= dresses-16: (with DISCUSS and COMMENT) Hi, Stephen, (Lloyd CC'ed, since IIRC he did work on the MD5 stuff) Thanks so much for your input! -- Please find my responses in-line... On 01/21/2014 12:52 PM, Stephen Farrell wrote: > (1) Section 5: Why mention only MD5 and SHA1? Why not > HMAC-SHA256? They are just examples. I guess we could add HMAC-SHA256, too. I have no objections to that. > As-is, implementers are likely to get this > wrong in various ways, e.g. allowing MD5 collisions to > be generated on purpose with different inputs perhaps > as a way to assign blame to an innocent victim. mm.. what's the attack you have in mind with these MD5 collisions? > If > HMAC-MD5 or better (*) HMAC-SHA256 were recommended > instead, it is far more likley that implementers will > do the right thing and it seems just as easy to do > today's right thing as what's mentioned here. To some extent, the idea is that you'd do MD5 or better. But at the end of the day, if MD5 is too much for you, even something weaker than MD5 would be better than the "embed the MAC address" thing we do today. > (*) Even though HMAC-MD5 is still ok, its better > (for audit reasons) if we reduce the number of > copies of MD5 runtime code on systems and do not > introduce new instances of that code. That's one of the reasons MD5 is listed: most systems already implement it. > (2) Why might a sys admin want to display the > secret key? e.g., you want a replacement system to generate the same addresses. > If there's a reason shouldn't you say > so that coders don't do the wrong thing? The > concern is that once established, this key might > be re-used for other purposes and display might > then become an interesting attack vector. Just double-checking: you argue that if it can be changed, systems would use the same key for other purposes, and hence it would leak out? > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - Probably not worth investigating, but I'd wonder if a > bad-actor with the 64 bit prefix to play about with > could force an IID on a node that used plain MD5 with a > guessable or known secret_key. As noted in the I-D, for obvious reasons the security of this system relies on the secret key being secret. > I don't think that's > doable today but its yet another reason to avoid very > outdated hash functions like md5. This is a non-issue > if discuss#1 is resolved by ditching MD5. To be quite honest, I think that MD5 is perfectly fine for this use case (for instance, it's not unusual for nodes to randomize the TCP SEQ with MD5). And since other hash functions are mentioned, one would expect that a developer that has something better available, would go for something better. That said, I'm not "married" with MD5, and wouldn't care myself if it's ditched. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From Ray.Hunter@globis.net Sun Jan 26 23:23:28 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066C81A01D0 for ; Sun, 26 Jan 2014 23:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmpPsHwJgFAL for ; Sun, 26 Jan 2014 23:23:26 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id DADAF1A01CF for ; Sun, 26 Jan 2014 23:23:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id E2647870073; Mon, 27 Jan 2014 08:23:20 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwVCQn6r5MVg; Mon, 27 Jan 2014 08:23:20 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id C4C4A87006D; Mon, 27 Jan 2014 08:23:20 +0100 (CET) Message-ID: <52E60967.9040206@globis.net> Date: Mon, 27 Jan 2014 08:23:19 +0100 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: Update about draft-petrescu-ipv6-over-80211p-01.txt References: <52DBDCD3.6010600@gmail.com> In-Reply-To: <52DBDCD3.6010600@gmail.com> Content-Type: multipart/mixed; boundary="------------080307060409040006000309" X-Mailman-Approved-At: Mon, 03 Feb 2014 08:34:38 -0800 Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 07:23:28 -0000 This is a multi-part message in MIME format. --------------080307060409040006000309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I have read this draft. Thanks for sharing your experiences. Would 6LoWPan RFC6775 not be more appropriate for dealing with the issues identified in Section 5.6, when 802.11p is operating in OCB mode? I realise that in a vehicular scenario, maintaining the mesh under network may prove challenging. Alexandru Petrescu wrote: > Hello 6MAN participants, > > This is an update you about draft-petrescu-ipv6-over-80211p-01.txt: > what happened with it since November last year? > > - slight textual modifications about one author affiliation. > - announced on v6ops and on 6lo. Received some private comments about > its usefulness and where to discuss it. > > Please comment on this draft. > > http://tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-01 > > "Transmission of IPv6 Packets over IEEE 802.11p Networks" > draft-petrescu-ipv6-over-80211p-01.txt > > "In order to transmit IPv6 packets on IEEE 802.11p networks there is a > need to define a few parameters such as the recommended Maximum > Transmission Unit size, the header format preceding the IPv6 base > header, the Type value within it, and others. This document > describes these parameters for IPv6 and IEEE 802.11p networks; it > portrays the layering of IPv6 on 802.11p similarly to other known > 802.11 and Ethernet layers, by using an existing Ethernet Adaptation > Layer. > > In addition, the document attempts to list what is different in > 802.11p compared to more 'traditional' 802.11a/b/g/n layers, layers > over which IPv6 protocols run ok. Most notably, the operation > outside the context of a BSS (OCB) has impact on IPv6 handover > behaviour and on IPv6 security. > > An example of an IPv6 packet captured while transmitted over an IEEE > 802.11p link is given." > > Alex > > --- > Ce courrier électronique ne contient aucun virus ou logiciel > malveillant parce que la protection avast! Antivirus est active. > http://www.avast.com > > -- Ray Hunter Ray.Hunter@globis.net Globis Consulting BV, Weegschaalstraat 3, 5632CW Eindhoven NL Registered at the KvK, Eindhoven, under number BV 17098279 mobile: +31 620 363864 --------------080307060409040006000309 Content-Type: text/x-vcard; charset=utf-8; name="Ray_Hunter.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Ray_Hunter.vcf" begin:vcard fn:Ray Hunter n:Hunter;Ray org:Globis Consulting BV adr:;;Fazantlaan23;Eindhoven;;5613CB;The Netherlands email;internet:Ray.Hunter@globis.net tel;cell:+31 620 363864 x-mozilla-html:FALSE url:http://www.globis.net version:2.1 end:vcard --------------080307060409040006000309-- From nordmark@sonic.net Wed Jan 22 13:48:38 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8681A0451 for ; Wed, 22 Jan 2014 13:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVnNpaNWsTkV for ; Wed, 22 Jan 2014 13:48:37 -0800 (PST) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id ABA281A0111 for ; Wed, 22 Jan 2014 13:48:37 -0800 (PST) Received: from [10.0.1.44] (184-23-158-201.dsl.dynamic.sonic.net [184.23.158.201]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s0MLmDbW017286 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 22 Jan 2014 13:48:14 -0800 Message-ID: <52E03C9D.7010605@sonic.net> Date: Wed, 22 Jan 2014 13:48:13 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ole Troan , Lorenzo Colitti Subject: Re: Reducing the battery impact of ND References: <52D96663.6060005@sonic.net> <52DA0ABA.8030903@acm.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;hBbS5K6D4xGGksecJ1f4WQ== M;EOvu5K6D4xGGksecJ1f4WQ== X-Mailman-Approved-At: Mon, 03 Feb 2014 08:34:38 -0800 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Erik Nordmark , Andrew Yourtchenko , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 21:48:39 -0000 On 1/21/14 2:35 PM, Ole Troan wrote: > Lorenzo, > >> One of your "yes please" below is a change to ND - Andrew's b) about >> restarting RS would require a (small) standards update. >> >> >> We should try to get that into draft-6man-resilient-rs. >> >> It seems to be out of scope for the problem resilent-rs set out to solve which was loss issues for the initial RS. It might not be wise to expand that drafts scope to also cover (part of) efficient-nd. > > the abstract has the following text: > "Furthermore, on some links, unsolicited multicast > Router Advertisements are never sent and the mechanism in this > document is intended to work even in such scenarios." I think that text can be read in different ways. One way is within the scope of the initial configuration (which is what the RSs are for) is robust even if there are no unsolicited multicast RAs. Another way is that the document intended to get rid of the need for unsolicited multicast RAs. Based on the title, name, and content of the document, my conclusion is that the first reading is much more accurate. >> To my mind, sending an RS when the RA lifetime is about to expire is a robustness fix, not an efficiency fix. In a world where IPv6 is optional and IPv4 is the main protocol, just having your IPv6 address expire is not necessarily a problem. But in a world where IPv6 is the main protocol, then hosts will probably want to try harder to keep their IPv6 address around. > > I believe you have found a bug in the resilient-rs draft. > could you reply to the WGLC thread for that document and notify the authors? It makes sense having the document be clear on its scope, so some clarification is in order. Regards, Erik From nordmark@sonic.net Wed Jan 22 14:15:08 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1C61A04DD for ; Wed, 22 Jan 2014 14:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WO8zVDxqiuSc for ; Wed, 22 Jan 2014 14:15:07 -0800 (PST) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id 43E3F1A04A2 for ; Wed, 22 Jan 2014 14:14:35 -0800 (PST) Received: from [10.0.1.44] (184-23-158-201.dsl.dynamic.sonic.net [184.23.158.201]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s0MMEVl4008274 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 22 Jan 2014 14:14:31 -0800 Message-ID: <52E042C7.2090906@sonic.net> Date: Wed, 22 Jan 2014 14:14:31 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ole Troan , Erik Nordmark Subject: Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt References: <20131021233827.32495.34424.idtracker@ietfa.amsl.com> <6299FD64-01A9-4F19-B271-9891AFCA3269@gmail.com> <52E03E13.8080800@acm.org> <25AE033D-3671-479E-A739-6C5F7DF221E1@employees.org> In-Reply-To: <25AE033D-3671-479E-A739-6C5F7DF221E1@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;zhQ0kbKD4xGbqtRAJ1f4WQ== M;mN1kkbKD4xGbqtRAJ1f4WQ== X-Mailman-Approved-At: Mon, 03 Feb 2014 08:34:38 -0800 Cc: draft-ietf-6man-resilient-rs@tools.ietf.org, 6man WG , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 22:15:08 -0000 Ole, Are you speaking as a co-chair or as a WG contributor? I don't know whether this is your gauge of WG consensus or personal opinion. Thanks, Erik > I don't think this document should make any reference to links that does not send unsolicited RAs. > that doesn't mean it cannot say how router discovery can work more robustly. > > cheers, > Ole > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From spencerdawkins.ietf@gmail.com Thu Jan 23 06:22:11 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F061A041A; Thu, 23 Jan 2014 06:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_Yyv7Lez9qa; Thu, 23 Jan 2014 06:22:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6051A00FC; Thu, 23 Jan 2014 06:22:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Spencer Dawkins" To: The IESG Subject: Spencer Dawkins' No Objection on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140123142209.16930.14524.idtracker@ietfa.amsl.com> Date: Thu, 23 Jan 2014 06:22:09 -0800 X-Mailman-Approved-At: Mon, 03 Feb 2014 08:34:38 -0800 Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, draft-ietf-6man-stable-privacy-addresses@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 14:22:11 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-6man-stable-privacy-addresses-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is a very well-written and clear document. Thank you for that. From l.wood@surrey.ac.uk Thu Jan 23 13:58:58 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2FA1A0434; Thu, 23 Jan 2014 13:58:58 -0800 (PST) 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=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rg4fuYIpdw-m; Thu, 23 Jan 2014 13:58:56 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.153]) by ietfa.amsl.com (Postfix) with ESMTP id DB9571A0433; Thu, 23 Jan 2014 13:58:55 -0800 (PST) Received: from [195.245.231.67:7989] by server-17.bemta-5.messagelabs.com id C3/A5-19152-D9091E25; Thu, 23 Jan 2014 21:58:53 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-13.tower-82.messagelabs.com!1390514333!36740063!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7559 invoked from network); 23 Jan 2014 21:58:53 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-13.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 23 Jan 2014 21:58:53 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Thu, 23 Jan 2014 21:58:52 +0000 From: To: , , , , Date: Thu, 23 Jan 2014 21:58:04 +0000 Subject: RE: Stephen Farrell's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS and COMMENT) Thread-Topic: Stephen Farrell's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS and COMMENT) Thread-Index: Ac8YY31nzkx2XZhUTPy9EdzXC3x9yQAIrQaz Message-ID: <290E20B455C66743BE178C5C84F1240847E63346E4@EXMB01CMS.surrey.ac.uk> References: <20140121155253.23475.70004.idtracker@ietfa.amsl.com> <52DE9E63.5050404@si6networks.com> <52DEA496.9000000@viagenie.ca> <52DEB873.1080500@cs.tcd.ie> <52DEC5C8.7080903@si6networks.com> <52E130A7.5050102@cisco.com>,<52E14FBB.1070901@si6networks.com> In-Reply-To: <52E14FBB.1070901@si6networks.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 03 Feb 2014 08:34:38 -0800 Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, draft-ietf-6man-stable-privacy-addresses@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 21:58:58 -0000 is the secret key sent over th e network? at that point, it would stop bein= g secret. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Fernando Gont [fgont@si6networks.com] Sent: 23 January 2014 17:22 To: Eliot Lear; Stephen Farrell; Simon Perreault; The IESG Cc: 6man-chairs@tools.ietf.org; ipv6@ietf.org; Wood L Dr (Electronic Eng);= draft-ietf-6man-stable-privacy-addresses@tools.ietf.org Subject: Re: Stephen Farrell's Discuss on draft-ietf-6man-stable-privacy-ad= dresses-16: (with DISCUSS and COMMENT) On 01/23/2014 12:09 PM, Eliot Lear wrote: > > On 1/21/14, 8:08 PM, Fernando Gont wrote: >> >>> If keeping it, I'd say give the example and then add a >>> security consideration that that interface might be >>> vulnerable (e.g. 'cat /proc/net/eth0/rfcxxx-secret' >> How about rather noting that the secret key should only be accessible by >> the system administrator? (i.e., non-RFC2119 recommend that implementers >> do the right thing :-) ) > > I agree with the requirement but I think Stephen raises an important > point, which is that it should be highlighted that the information is > sensitive. As such, implementations should constrain access to the > information, to the extent practicable. Furthermore, I understood > Stephen's point also to be that the private key information should not > be used for any other purpose. It's not actually a private key in the sense of private/public key.. Just a secret key. But yeah, I have no objections to adding some words on the topic. How about this: "Since the privacy of this system relies on the secrecy of the secret_key parameter, implementations should constraint access to it to the extent practicable (e.g., require superuser privileges to access it). Furthermore, in order to prevent leakages of the secret_key, this parameter should not be used for any other purposes than being a parameter to the scheme specified in this document" ? Thoughts? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nordmark@sonic.net Thu Jan 30 10:13:06 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62DF1A044D for ; Thu, 30 Jan 2014 10:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3mScjA_RHZM for ; Thu, 30 Jan 2014 10:13:05 -0800 (PST) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id 023931A0429 for ; Thu, 30 Jan 2014 10:13:04 -0800 (PST) Received: from [10.0.0.180] (75-94-129-28.sfo.clearwire-wmx.net [75.94.129.28] (may be forged)) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s0UICuoB007360 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 30 Jan 2014 10:12:58 -0800 Message-ID: <52EA9628.4020700@sonic.net> Date: Thu, 30 Jan 2014 10:12:56 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Erik Kline , Erik Nordmark Subject: Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt References: <20131021233827.32495.34424.idtracker@ietfa.amsl.com> <6299FD64-01A9-4F19-B271-9891AFCA3269@gmail.com> <52E9EFB9.9000402@acm.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-ID: C;cBbZJNqJ4xGnhNRAJ1f4WQ== M;BOKqJdqJ4xGnhNRAJ1f4WQ== X-Mailman-Approved-At: Mon, 03 Feb 2014 08:34:38 -0800 Cc: draft-ietf-6man-resilient-rs@tools.ietf.org, IETF IPv6 Mailing List , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 18:13:07 -0000 On 1/29/14 11:41 PM, Erik Kline wrote: > In such an approach when would the router stop unicasting RAs to a > particular address? Forever? Until NUD fails? What is the host was > gone for 30 seconds without the host noticing and as a result the > router saw a NUD failure. > I like your “until the router detects a NUD failure for the host” notion, I think. In that case, I think the host will either: Erik, Sorry for not being clear. That wasn't a proposal of mine but a prod for some clarification. It doesn't actually work (sorry for having been terse) since the host has no way to find out when the router saw a NUD failure and stopped with the unicasts. I wanted to illustrate that this is harder than it seems. I should have made that more obvious. > [1] enter into NUD detection from its perspective because communications are failing (no replies to packets sent), or NUD doesn't work that way - each side determines unreachable separately. Erik > > [2] it had to packets to send so didn’t notice anything, and then the RA timers get “low” and the host enters into the proposed “retry RSes (probably requiring multicast)” behaviour that launched this thread. > > I do agree that if a network is going to rely on RSes before it sends a periodic RA (say, because the network is one of these split horizon things) some guidelines for the RA-sending side are probably in order, but I’m not yet convinced it’s terribly complicated. > > …but maybe I just haven’t thought about it enough. > > -Erik (the lesser) > From huitema@microsoft.com Mon Feb 3 11:06:14 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358001A0162; Mon, 3 Feb 2014 11:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxoiW_Mw9srk; Mon, 3 Feb 2014 11:06:12 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0149.outbound.protection.outlook.com [207.46.163.149]) by ietfa.amsl.com (Postfix) with ESMTP id 76FA81A01F8; Mon, 3 Feb 2014 11:06:12 -0800 (PST) Received: from DM2PR03CA010.namprd03.prod.outlook.com (10.141.52.158) by BN1PR03MB023.namprd03.prod.outlook.com (10.255.224.41) with Microsoft SMTP Server (TLS) id 15.0.868.8; Mon, 3 Feb 2014 19:06:11 +0000 Received: from BN1BFFO11FD032.protection.gbl (2a01:111:f400:7c10::1:123) by DM2PR03CA010.outlook.office365.com (2a01:111:e400:2414::30) with Microsoft SMTP Server (TLS) id 15.0.868.8 via Frontend Transport; Mon, 3 Feb 2014 19:06:10 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD032.mail.protection.outlook.com (10.58.144.95) with Microsoft SMTP Server (TLS) id 15.0.856.14 via Frontend Transport; Mon, 3 Feb 2014 19:06:09 +0000 Received: from TK5EX14MBXC301.redmond.corp.microsoft.com ([169.254.1.10]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0174.002; Mon, 3 Feb 2014 19:05:15 +0000 From: Christian Huitema To: "l.wood@surrey.ac.uk" , "fgont@si6networks.com" , "stephen.farrell@cs.tcd.ie" , "iesg@ietf.org" Subject: RE: Stephen Farrell's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS and COMMENT) Thread-Topic: Stephen Farrell's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS and COMMENT) Thread-Index: AQHPFsD+YOme/d80rkOODnhQM2zvF5qPW/6AgAAWIYCAFIVp0A== Date: Mon, 3 Feb 2014 19:05:15 +0000 Message-ID: References: <20140121155253.23475.70004.idtracker@ietfa.amsl.com>, <52DE9E63.5050404@si6networks.com> <290E20B455C66743BE178C5C84F1240847E63346D8@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346D8@EXMB01CMS.surrey.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(189002)(199002)(93516002)(93136001)(6806004)(55846006)(80976001)(74706001)(81542001)(49866001)(86362001)(92726001)(50466002)(74876001)(94316002)(44976005)(23726002)(53806001)(56776001)(83072002)(54356001)(81686001)(56816005)(63696002)(47776003)(2656002)(76786001)(20776003)(31966008)(87266001)(77096001)(33656001)(79102001)(80022001)(94946001)(65816001)(74662001)(74502001)(74366001)(90146001)(92566001)(76796001)(76482001)(85306002)(50986001)(54316002)(85852003)(47976001)(81342001)(47736001)(4396001)(46406003)(2201001)(51856001)(66066001)(87936001)(81816001)(85806002)(46102001)(69226001)(47446002)(83322001)(59766001)(77982001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR03MB023; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:B0A87600.B364D6DB.B87531C1.D6C97E75.20100; InfoDomainNonexistentMX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 01110342A5 X-OriginatorOrg: microsoft.com Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "ipv6@ietf.org" , "draft-ietf-6man-stable-privacy-addresses@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 19:06:14 -0000 > MD5 is still useful as a checksum for really big files, where you're look= ing for accidental differences introduced by errors, and MD5's efficiency o= f computation is a win. But that says nothing about being tamper-proof. Thi= nk of it as a big CRC32, and CRC32 is not seen as having security propertie= s. But then, for applications like that, you can also use CRC64. -- Christian Huitema From hagen@jauu.net Mon Feb 3 12:47:45 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB3C1A0225 for ; Mon, 3 Feb 2014 12:47:45 -0800 (PST) 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=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1jS1JzmE0kl for ; Mon, 3 Feb 2014 12:47:43 -0800 (PST) Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2001:4d88:1ffa:82:880:aa0:9009:64ae]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1741A01FB for <6man@ietf.org>; Mon, 3 Feb 2014 12:47:43 -0800 (PST) Received: from pfeifer by Chamillionaire.breakpoint.cc with local (Exim 4.80) (envelope-from ) id 1WAQQI-0002cB-2F; Mon, 03 Feb 2014 21:47:18 +0100 Date: Mon, 3 Feb 2014 21:47:17 +0100 From: Hagen Paul Pfeifer To: Fernando Gont Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers Message-ID: <20140203204716.GD1519@virgo.local> References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6WlEvdN9Dv0WHSBl" Content-Disposition: inline In-Reply-To: <52EAF63A.7050108@si6networks.com> X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "C. M. Heard" , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 20:47:45 -0000 --6WlEvdN9Dv0WHSBl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline * Fernando Gont | 2014-01-30 22:02:50 [-0300]: >Folks, > >Mike Heard noted that the Uniform Format specified in RFC 6465 can't >possibly work.. and after giving some thought about it, it turns out >that implementing it would hamper the deployment of new transport protocols. > >We've written a short I-D that discussed the problem, and that proposes >an alternative, such that we achieve the same goal without possibly >messing with our Transport friends. :-) Hey Fernando, I realized that too and wrote an I-D (back in July 2011): http://tools.ietf.org/html/draft-pfeifer-6man-exthdr-res-01 Compared to your solution I propose to reserve a range. Hagen --6WlEvdN9Dv0WHSBl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlLwAFQACgkQSiKNRZg1DCKWSgCfUDby0RybYBNtOgq8fzVueM0g Av4AnjhWv0g4e3q+rrEz2+LeM9NxwvLW =vPBA -----END PGP SIGNATURE----- --6WlEvdN9Dv0WHSBl-- From brian.e.carpenter@gmail.com Mon Feb 3 13:43:44 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C9B1A01EE for ; Mon, 3 Feb 2014 13:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-0od-se9S3X for ; Mon, 3 Feb 2014 13:43:43 -0800 (PST) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 012AF1A0232 for <6man@ietf.org>; Mon, 3 Feb 2014 13:43:42 -0800 (PST) Received: by mail-pb0-f51.google.com with SMTP id un15so7525044pbc.24 for <6man@ietf.org>; Mon, 03 Feb 2014 13:43:43 -0800 (PST) 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=9o6VxIGIF/n/BRtfKI2whpTzUu0dKCm4/NcOwBC0W/Y=; b=JQ/9USF4Si9RrQwra8MU6rN69Hwf/Jw5ja5SKL19eHUWAvfXeCy+jmS2lRDWtK7DL7 LEWY8zyIKLfbSZw8dLDf2nicZpjaeVYIbRbeugvuvKyckAeYvVZ4rl84DeTnsRmTZ+B6 ysZHpStD12DPyhjAoBGivZndMU1vkV4+iLb6qNbRrh196iFSJetOnO6iuckilyPMjy8o VEosVfXuJwf/HvloCXS/KY8+UOFq2qFcd4xu0veqetIoUzNV7r+C4T0ND3x0M5zesnhm 3z/aiLWcFkkhU00AX3tPqZJumy0ILREiHl1/QBLfWe6UcAL/HVNy93NnPge9UbPxXJSc C3Gg== X-Received: by 10.66.146.229 with SMTP id tf5mr40092115pab.50.1391463822991; Mon, 03 Feb 2014 13:43:42 -0800 (PST) Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id rb6sm23599580pbb.41.2014.02.03.13.43.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Feb 2014 13:43:42 -0800 (PST) Message-ID: <52F00D8C.8060501@gmail.com> Date: Tue, 04 Feb 2014 10:43:40 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hagen Paul Pfeifer Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <20140203204716.GD1519@virgo.local> In-Reply-To: <20140203204716.GD1519@virgo.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "C. M. Heard" , Fernando Gont , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 21:43:44 -0000 On 04/02/2014 09:47, Hagen Paul Pfeifer wrote: > * Fernando Gont | 2014-01-30 22:02:50 [-0300]: > >> Folks, >> >> Mike Heard noted that the Uniform Format specified in RFC 6465 can't >> possibly work.. and after giving some thought about it, it turns out >> that implementing it would hamper the deployment of new transport protocols. >> >> We've written a short I-D that discussed the problem, and that proposes >> an alternative, such that we achieve the same goal without possibly >> messing with our Transport friends. :-) > > Hey Fernando, I realized that too and wrote an I-D (back in July 2011): > > http://tools.ietf.org/html/draft-pfeifer-6man-exthdr-res-01 > > Compared to your solution I propose to reserve a range. Either solution works, but the firewall implementors might have a preference one way or the other. RFC 7045 says "Therefore, it is important that forwarding nodes that inspect IPv6 headers be able to parse all defined extension headers and deal with them appropriately,..." So the question is whether they would find a reserved range or a subtype easier to parse. Brian From hagen@jauu.net Mon Feb 3 14:00:42 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6E41A0226 for ; Mon, 3 Feb 2014 14:00:42 -0800 (PST) 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=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7evnsafeCljl for ; Mon, 3 Feb 2014 14:00:40 -0800 (PST) Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2001:4d88:1ffa:82:880:aa0:9009:64ae]) by ietfa.amsl.com (Postfix) with ESMTP id 873691A0208 for <6man@ietf.org>; Mon, 3 Feb 2014 14:00:40 -0800 (PST) Received: from pfeifer by Chamillionaire.breakpoint.cc with local (Exim 4.80) (envelope-from ) id 1WARZ7-00054x-J5; Mon, 03 Feb 2014 23:00:29 +0100 Date: Mon, 3 Feb 2014 23:00:28 +0100 From: Hagen Paul Pfeifer To: Brian E Carpenter Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers Message-ID: <20140203220028.GA7123@virgo.local> References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <20140203204716.GD1519@virgo.local> <52F00D8C.8060501@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: <52F00D8C.8060501@gmail.com> X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "C. M. Heard" , Fernando Gont , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 22:00:42 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline * Brian E Carpenter | 2014-02-04 10:43:40 [+1300]: >Either solution works, but the firewall implementors might >have a preference one way or the other. RFC 7045 says >"Therefore, it is important that forwarding >nodes that inspect IPv6 headers be able to parse all defined >extension headers and deal with them appropriately,..." >So the question is whether they would find a reserved >range or a subtype easier to parse. In the appendix of draft-pfeifer-6man-exthdr-res-01 I provided a patch against Linux net-next-2.6 (see end of this email). In the end the compare do not matter that match because one additional cmp is used which is fast. diff --git a/net/ipv6/exthdrs_core.c b/net/ipv6/exthdrs_core.c index 14ed0a9..d7f2e97 100644 --- a/net/ipv6/exthdrs_core.c +++ b/net/ipv6/exthdrs_core.c @@ -4,6 +4,9 @@ */ #include +#define IP6_EXTHDR_RESERVED_MIN 245 +#define IP6_EXTHDR_RESERVED_MAX 252 + /* * find out if nxthdr is a well-known extension header or a protocol */ @@ -18,7 +21,8 @@ int ipv6_ext_hdr(u8 nexthdr) (nexthdr == NEXTHDR_FRAGMENT) || (nexthdr == NEXTHDR_AUTH) || (nexthdr == NEXTHDR_NONE) || - (nexthdr == NEXTHDR_DEST); + (nexthdr == NEXTHDR_DEST) || + (nexthdr >= IP6_EXTHDR_RESERVED_MIN && + nexthdr <= IP6_EXTHDR_RESERVED_MAX); } --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlLwEXwACgkQSiKNRZg1DCJ7uwCbBQORtPATi19Pfbq5zSzUrcpB 4nkAn2fGqR/wTX/w92f2j7UQAtA820nT =347t -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From brian.e.carpenter@gmail.com Mon Feb 3 15:09:46 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7B01A026A for ; Mon, 3 Feb 2014 15:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2pbniY__aly for ; Mon, 3 Feb 2014 15:09:44 -0800 (PST) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF591A0265 for <6man@ietf.org>; Mon, 3 Feb 2014 15:09:44 -0800 (PST) Received: by mail-pb0-f53.google.com with SMTP id md12so7633471pbc.40 for <6man@ietf.org>; Mon, 03 Feb 2014 15:09:44 -0800 (PST) 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=JzEjAaD/llHsajD1pZjq00XMtXTn3XpMOYYJCEUpqzg=; b=b4xwO04xoWk1aAaYNAclDo43Uc6N3TQlwEPYahoeI6RSdf8DbrBhDNdILePl8epArn C9nIw4cH9No0r6qvVI9KtM2cQjZXEoHvb7PbCGONNqo7nOikQD3F2Z+5whyT5hGXqFo+ 9nqPeyubIO0K1UIWR8XpV3iUwPvDRVTboWHem9jOoNR/lYjuAc/FNMl44dL4z4ObCkJ7 2I8Gwo+zH0oG5h9hATmJ6dH0RNNWRMI/AlwYz2nIEywv23c3tdRMi/y18EgX6cCky2FK E61ZnBSPvKijpCu7QWh6jGl7ailAHBstXQLJP9wCfZduaygX0Tcu+5SoKCyOK3dQIUBF jmGQ== X-Received: by 10.68.114.163 with SMTP id jh3mr39381853pbb.99.1391468984085; Mon, 03 Feb 2014 15:09:44 -0800 (PST) Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id ac5sm30305833pbc.37.2014.02.03.15.09.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Feb 2014 15:09:42 -0800 (PST) Message-ID: <52F021B4.20003@gmail.com> Date: Tue, 04 Feb 2014 12:09:40 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hagen Paul Pfeifer Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <20140203204716.GD1519@virgo.local> <52F00D8C.8060501@gmail.com> <20140203220028.GA7123@virgo.local> In-Reply-To: <20140203220028.GA7123@virgo.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "C. M. Heard" , Fernando Gont , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 23:09:46 -0000 On 04/02/2014 11:00, Hagen Paul Pfeifer wrote: > * Brian E Carpenter | 2014-02-04 10:43:40 [+1300]: > >> Either solution works, but the firewall implementors might >> have a preference one way or the other. RFC 7045 says >> "Therefore, it is important that forwarding >> nodes that inspect IPv6 headers be able to parse all defined >> extension headers and deal with them appropriately,..." >> So the question is whether they would find a reserved >> range or a subtype easier to parse. > > In the appendix of draft-pfeifer-6man-exthdr-res-01 I provided a patch against > Linux net-next-2.6 (see end of this email). In the end the compare do not > matter that match because one additional cmp is used which is fast. By the way, your code extract seems to show exactly the problem that inspired RFC 7045: the list of nexthdrs needs to include all of them as per the new registry at http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header Brian > > > > diff --git a/net/ipv6/exthdrs_core.c b/net/ipv6/exthdrs_core.c > index 14ed0a9..d7f2e97 100644 > --- a/net/ipv6/exthdrs_core.c > +++ b/net/ipv6/exthdrs_core.c > @@ -4,6 +4,9 @@ > */ > #include > > +#define IP6_EXTHDR_RESERVED_MIN 245 > +#define IP6_EXTHDR_RESERVED_MAX 252 > + > /* > * find out if nxthdr is a well-known extension header or a protocol > */ > @@ -18,7 +21,8 @@ int ipv6_ext_hdr(u8 nexthdr) > (nexthdr == NEXTHDR_FRAGMENT) || > (nexthdr == NEXTHDR_AUTH) || > (nexthdr == NEXTHDR_NONE) || > - (nexthdr == NEXTHDR_DEST); > + (nexthdr == NEXTHDR_DEST) || > + (nexthdr >= IP6_EXTHDR_RESERVED_MIN && > + nexthdr <= IP6_EXTHDR_RESERVED_MAX); > } From mawatari@jpix.ad.jp Tue Feb 4 00:34:13 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72091A03A5 for ; Tue, 4 Feb 2014 00:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.908 X-Spam-Level: ** X-Spam-Status: No, score=2.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MANGLED_NAIL=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLnSZS-ReTSH for ; Tue, 4 Feb 2014 00:34:12 -0800 (PST) Received: from mail-gw.kbmail.jp (mail3179.kbmail.jp [111.87.219.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7834D1A03A4 for ; Tue, 4 Feb 2014 00:34:10 -0800 (PST) X-matriXscan-EoH: Received: from bmlmta011.kbmail.jp (bmlmta011-MM [10.188.50.11]) by mail-gw.kbmail.jp (kbmail) with ESMTP id 7E2DAB20002 for ; Tue, 4 Feb 2014 17:34:09 +0900 (JST) Received: from ([202.90.12.1]) by bmlmta011.kbmail.jp id 52f0a6010000c9cb000062dc000063256800000fca38; Tue, 04 Feb 2014 17:34:09 +0900 Date: Tue, 04 Feb 2014 17:34:12 +0900 From: MAWATARI Masataka To: ipv6@ietf.org Subject: Fw: [Technical Errata Reported] RFC6890 (3879) Message-Id: <20140204173412.3463.8FE1F57E@jpix.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.65 [ja] X-MXM-DELIVERY-TYPE: 3 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 08:34:14 -0000 Dear Colleagues, I reported about the global scope regarding 2001::/32 and fc00::/7 as an errata. http://www.rfc-editor.org/errata_search.php?rfc=6890&eid=3879 Regards, Masataka MAWATARI Forwarded by MAWATARI Masataka ----------------------- Original Message ----------------------- From: RFC Errata System Date: Mon, 3 Feb 2014 21:44:44 -0800 (PST) Subject: [Technical Errata Reported] RFC6890 (3879) ---- The following errata report has been submitted for RFC6890, "Special-Purpose IP Address Registries". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6890&eid=3879 -------------------------------------- Type: Technical Reported by: Masataka MAWATARI Section: 2.2.3 Original Text ------------- +----------------------+----------------+ | Attribute | Value | +----------------------+----------------+ | Address Block | 2001::/32 | | Name | TEREDO | | RFC | [RFC4380] | | Allocation Date | January 2006 | | Termination Date | N/A | | Source | True | | Destination | True | | Forwardable | True | | Global | False | | Reserved-by-Protocol | False | +----------------------+----------------+ Table 23: TEREDO +----------------------+--------------+ | Attribute | Value | +----------------------+--------------+ | Address Block | fc00::/7 | | Name | Unique-Local | | RFC | [RFC4193] | | Allocation Date | October 2005 | | Termination Date | N/A | | Source | True | | Destination | True | | Forwardable | True | | Global | False | | Reserved-by-Protocol | False | +----------------------+--------------+ Table 28: Unique-Local Corrected Text -------------- +----------------------+----------------+ | Attribute | Value | +----------------------+----------------+ | Address Block | 2001::/32 | | Name | TEREDO | | RFC | [RFC4380] | | Allocation Date | January 2006 | | Termination Date | N/A | | Source | True | | Destination | True | | Forwardable | True | | Global | N/A [RFC4380] | | Reserved-by-Protocol | False | +----------------------+----------------+ Table 23: TEREDO +----------------------+----------------+ | Attribute | Value | +----------------------+----------------+ | Address Block | fc00::/7 | | Name | Unique-Local | | RFC | [RFC4193] | | Allocation Date | October 2005 | | Termination Date | N/A | | Source | True | | Destination | True | | Forwardable | True | | Global | N/A [RFC4193] | | Reserved-by-Protocol | False | +----------------------+----------------+ Table 28: Unique-Local Notes ----- The global scope of TEREDO prefix (2001::/32) and Unique-Local prefix (fc00::/7) is not false. The proposed revision is N/A with reference to each RFC. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6890 (draft-bonica-special-purpose-07) -------------------------------------- Title : Special-Purpose IP Address Registries Publication Date : April 2013 Author(s) : M. Cotton, L. Vegoda, R. Bonica, Ed., B. Haberman Category : BEST CURRENT PRACTICE Source : IETF - NON WORKING GROUP Area : N/A Stream : IETF Verifying Party : IESG --------------------- Original Message Ends -------------------- From furry13@gmail.com Tue Feb 4 06:20:58 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9C81A0211 for ; Tue, 4 Feb 2014 06:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYdoFY_ALsyL for ; Tue, 4 Feb 2014 06:20:55 -0800 (PST) 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 2999F1A00EC for <6man@ietf.org>; Tue, 4 Feb 2014 06:20:55 -0800 (PST) Received: by mail-qc0-f175.google.com with SMTP id x13so13385719qcv.20 for <6man@ietf.org>; Tue, 04 Feb 2014 06:20:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=umOf7YHn6mRkzVpoEmq6wUTxlVpPzMOJVqwjSZ0ZCUY=; b=UxMPkTH1yuyIIQcytOgMVzWOjTBFanDdloZe6Hktdxpln8yrCWgNiExFwqzele0U9+ hXEyS69tXFDAMNxWF3bVrnTfnPag3uHgj/eyd5psWeh0O7StrOaENSy0U5vGY6oAdzHv gXXHsIFQrfJ4siBzgDGfmEtkJ2PpFsB778nzZLug/bMJ5T7A0M3Olvv58+RdWNev5oS4 f4y2PcX1lf2XqFyDSk8UGn3yY9WZI99jJ99bCLhcfSCGvv/QScx+DjvHVNaBFR6CM9Fd TdAb96op3O0hLRsISUK6Oj0o5siw2IjvNdoTJpXQ13TgsBITluItMj2DkPjOhqBZ/Bg9 w0uA== X-Received: by 10.224.75.138 with SMTP id y10mr67230745qaj.72.1391523654679; Tue, 04 Feb 2014 06:20:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.40.197 with HTTP; Tue, 4 Feb 2014 06:20:34 -0800 (PST) In-Reply-To: <52EAF63A.7050108@si6networks.com> References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> From: Jen Linkova Date: Tue, 4 Feb 2014 15:20:34 +0100 Message-ID: Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers To: Fernando Gont Content-Type: text/plain; charset=ISO-8859-1 Cc: "C. M. Heard" , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 14:20:58 -0000 Hi Fernando, On Fri, Jan 31, 2014 at 2:02 AM, Fernando Gont wrote: > Mike Heard noted that the Uniform Format specified in RFC 6465 can't > possibly work.. and after giving some thought about it, it turns out > that implementing it would hamper the deployment of new transport protocols. > > We've written a short I-D that discussed the problem, and that proposes > an alternative, such that we achieve the same goal without possibly > messing with our Transport friends. :-) > > The I-D is available at: > Somehow that proposed Universal Extension Header looks exactly like an Options Extension Header to me. Am I missing something? I'm trying to use my imagination but couldn't see any possible scenario when UEH would work and Options header would not. > -------- Original Message -------- > Subject: New Version Notification for > draft-gont-6man-ipv6-universal-extension-header-00.txt > Date: Thu, 30 Jan 2014 15:07:40 -0800 > From: internet-drafts@ietf.org > To: Fernando Gont , "Fernando Gont" > , "Shucheng LIU (Will)" , > Will (Shucheng) Liu > > > A new version of I-D, draft-gont-6man-ipv6-universal-extension-header-00.txt > has been successfully submitted by Fernando Gont and posted to the > IETF repository. > > Name: draft-gont-6man-ipv6-universal-extension-header > Revision: 00 > Title: IPv6 Universal Extension Header > Document date: 2014-01-31 > Group: Individual Submission > Pages: 6 > URL: > http://www.ietf.org/internet-drafts/draft-gont-6man-ipv6-universal-extension-header-00.txt > Status: > https://datatracker.ietf.org/doc/draft-gont-6man-ipv6-universal-extension-header/ > Htmlized: > http://tools.ietf.org/html/draft-gont-6man-ipv6-universal-extension-header-00 > > > Abstract: > This document analyzes a problem in the Uniform Format for IPv6 > Extension Headers specified in RFC 6564, which results in forwarding > nodes and middle-boxes not being able to process an IPv6 Header Chain > if it contains an unrecognized IPv6 Extension Header that follows the > aforementioned Uniform Format. Additionally, it specifies a new IPv6 > Extension Header - the Universal Extension Header - that overcomes > the aforementioned problem, and enables the extensibility of IPv6 > without impairing middleboxes that need to process the entire IPv6 > Header Chain. Finally, this document formally updates RFC 6564 > > > > > > 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 > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- SY, Jen Linkova aka Furry From fernando@gont.com.ar Tue Feb 4 11:19:18 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76CC1A01C6 for ; Tue, 4 Feb 2014 11:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qLLow_bMY75 for ; Tue, 4 Feb 2014 11:19:15 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8AF1A0127 for <6man@ietf.org>; Tue, 4 Feb 2014 11:19:15 -0800 (PST) Received: from [2001:5c0:1000:a::d7f] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WAlWZ-00030y-G8; Tue, 04 Feb 2014 20:19:11 +0100 Message-ID: <52F13D1D.9050800@gont.com.ar> Date: Tue, 04 Feb 2014 16:18:53 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jen Linkova , Fernando Gont Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "C. M. Heard" , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 19:19:19 -0000 Hi, Jen, On 02/04/2014 11:20 AM, Jen Linkova wrote: >> We've written a short I-D that discussed the problem, and that proposes >> an alternative, such that we achieve the same goal without possibly >> messing with our Transport friends. :-) >> >> The I-D is available at: >> > > Somehow that proposed Universal Extension Header looks exactly like an > Options Extension Header to me. > Am I missing something? I'm trying to use my imagination but couldn't > see any possible scenario when UEH would work and Options header would > not. Not sure what you mean. But please let me provide an example: Let's say that, tomorrow, the IETF standardizes the GTP (Google Transport Protocol :-)), and it is assigned the Next Header value 0xFF (I'm assuming this one is not currently assigned, bbut I'm not checking the IANA registry right now). Say a middle-box receives a packet that simply encapsulates GTP in IPv6, and that middlebox does not yet support GTP. If the middle-box tries to interpret the GTP header as in RFC6465, it will certainly fail. The reason? -- RFC 6465 implicitly assumes that every new Next Header will employ the RFC6465 format. This may be sensible for new *extension headers*, but certainly not for new transport protocols. And since transport protocols and extension headers share the same namespace (see RFC7045), this is a problem. What we did in our I-D is specify a new Extension Header, that is assigned a Next-Header value. Let us assume that our proposal moves forward, and the UEH is assigned the next header value 0xfe. If a middle-box supports UEH but does not support our (fictitious) GTP protocol above, then, if a GTP packet encapsulated in IPv6 is received, GTP will be identified as an "upper-layer protocol", rather than as UEH (since the Next Header value will be 0xff, rather than UEH's 0xfe). Clearly, another way to go is to reserve part of the IANA's Next Header namespace for RFC6465, and leave the rest for transport protocols -- as suggested by Hagen. What's clear is that the only way in which RFC6465 can possibly work is if the middle-box has some a-priori knowledge that what is being encapsulated follows RFC6465 -- whether as a result of a reserved range (as originally proposed by Hagen) or by specifying a single UEH, and then encoding all possible future "extension headers" as subtypes of UEH. Please do let me know if the above clarifies our rationale... P.S.: FWIW, we're working together with Hagen to offer 6man a more unified document that discusses possible approaches, pro's nd con's, etc. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From suresh.krishnan@ericsson.com Tue Feb 4 20:06:49 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285431A0023 for ; Tue, 4 Feb 2014 20:06:49 -0800 (PST) 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=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVX8-SLPzDWo for ; Tue, 4 Feb 2014 20:06:46 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 555861A0021 for <6man@ietf.org>; Tue, 4 Feb 2014 20:06:46 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-19-52f1b8d13ce9 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 12.0B.12743.1D8B1F25; Wed, 5 Feb 2014 05:06:41 +0100 (CET) Received: from [164.48.125.18] (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.87) with Microsoft SMTP Server (TLS) id 14.2.347.0; Tue, 4 Feb 2014 23:06:43 -0500 Message-ID: <52F1B8CE.4070803@ericsson.com> Date: Tue, 4 Feb 2014 23:06:38 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Fernando Gont , "6man@ietf.org" <6man@ietf.org>, "Will Liu (Shucheng)" , "C. M. Heard" Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> In-Reply-To: <52EAF63A.7050108@si6networks.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [147.117.188.8] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUyuXRPuO7FHR+DDE6+MrZYueIuk8WTVW/Y LG7smcNisf3ie2YHFo+WI29ZPZYs+cnkcfGSsseHQz3sASxRXDYpqTmZZalF+nYJXBlz3/az FXxUrXiy/SJ7A2OrfBcjB4eEgInE5h8WXYycQKaYxIV769m6GLk4hASOMErsO7eGFSQhJLCF UaLzFjNIPa+AtsSyaeogYRYBFYmj3xvZQGw2oDEbdn5mArFFBcIk2i/MZAaxeQUEJU7OfMIC MlNEYD6jxN5r68EahAW8JS78vcEOMT9Z4kzLUrBmTgF9iQ8fF4PtZRawlbgw5zoLhC0vsf3t HGaIek2JrWu+s0IcrSjx4vhPpgmMgrOQ7JuFpH0WkvYFjMyrGDlKi1PLctONDDYxAgP3mASb 7g7GPS8tDzFKc7AoifN+eescJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoExTrPy//PN7/9p P2ZRsqqva3B92L4vX3T138WzL7LP8n+VLZX3bbLAPVtNtd+Tr3Oe535vMmfxxLVLPp3s2pkd tHbOtHBDPZYAE6ntxRuT74fsYNLa3895MOFHrlGECENH4PH4rxLW05fFuG8V/8iZw7xm+/bb queXvO5WefOv3/o6R7XFb3thJZbijERDLeai4kQAAkxsrioCAAA= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 04:06:49 -0000 Hi Fernando, Sorry for the long mail, but there is a lot of history here. The short version is "Yes we wanted to do this as well, but the WG didn't want to waste a protocol number for something that may never be used" Now for the long version: When we set out to work on what became RFC6564, this was the *exact* problem we set out to solve. e.g. If you look at draft-ietf-6man-exthdr-00 differentiating between unknown extension headers and unknown upper layer protocols was an explicit goal "One key advantage of using such a generic IPv6 extension header is that it allows nodes to distinguish between unknown extension headers and unknown upper layer protocols, which was not possible earlier. Another one is that this generic extension header conserves values in the IPv4 protocol numbers registry." But unfortunately, it turns out that this was not really a problem the WG wanted to solve with RFC6564 :-). The documents that lead up to RFC6564 (draft-krishnan-ipv6-exthdr-*) and the first two versions of draft-ietf-6man-exthdr actually had this idea of an assigned code point all along. After WG adoption and subsequent discussion there was severe opposition to allocating a protocol number without knowing whether there will be any ipv6 extension headers ever defined in the future. The draft was changed in version -02 to not request an IANA codepoint anymore. Diffs are here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-6man-exthdr-02.txt I think Thomas Narten's comment summarized the wg feeling at the time the best. "My general sense is that this work is mostly just good common sense advice to someone who has a need to define a new extension type. But until we see such a concrete proposal, I am not convinced (yet) that we should define anything new that suggests people go change implementations or allocate code points. Both are premature." Thanks Suresh On 01/30/2014 08:02 PM, Fernando Gont wrote: > Folks, > > Mike Heard noted that the Uniform Format specified in RFC 6465 can't > possibly work.. and after giving some thought about it, it turns out > that implementing it would hamper the deployment of new transport protocols. > > We've written a short I-D that discussed the problem, and that proposes > an alternative, such that we achieve the same goal without possibly > messing with our Transport friends. :-) > > The I-D is available at: > > > Thanks! > > Best regards, > Fernando > > > > > -------- Original Message -------- > Subject: New Version Notification for > draft-gont-6man-ipv6-universal-extension-header-00.txt > Date: Thu, 30 Jan 2014 15:07:40 -0800 > From: internet-drafts@ietf.org > To: Fernando Gont , "Fernando Gont" > , "Shucheng LIU (Will)" , > Will (Shucheng) Liu > > > A new version of I-D, draft-gont-6man-ipv6-universal-extension-header-00.txt > has been successfully submitted by Fernando Gont and posted to the > IETF repository. > > Name: draft-gont-6man-ipv6-universal-extension-header > Revision: 00 > Title: IPv6 Universal Extension Header > Document date: 2014-01-31 > Group: Individual Submission > Pages: 6 > URL: > http://www.ietf.org/internet-drafts/draft-gont-6man-ipv6-universal-extension-header-00.txt > Status: > https://datatracker.ietf.org/doc/draft-gont-6man-ipv6-universal-extension-header/ > Htmlized: > http://tools.ietf.org/html/draft-gont-6man-ipv6-universal-extension-header-00 > > > Abstract: > This document analyzes a problem in the Uniform Format for IPv6 > Extension Headers specified in RFC 6564, which results in forwarding > nodes and middle-boxes not being able to process an IPv6 Header Chain > if it contains an unrecognized IPv6 Extension Header that follows the > aforementioned Uniform Format. Additionally, it specifies a new IPv6 > Extension Header - the Universal Extension Header - that overcomes > the aforementioned problem, and enables the extensibility of IPv6 > without impairing middleboxes that need to process the entire IPv6 > Header Chain. Finally, this document formally updates RFC 6564 > > > > > > 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 > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From dougb@dougbarton.us Tue Feb 4 20:17:15 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D32B1A0020; Tue, 4 Feb 2014 20:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Mcc8khGxiu0; Tue, 4 Feb 2014 20:17:13 -0800 (PST) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id D5BA61A0025; Tue, 4 Feb 2014 20:17:10 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:f5ba:4b6d:93ee:711a] (unknown [IPv6:2001:470:d:5e7:f5ba:4b6d:93ee:711a]) by dougbarton.us (Postfix) with ESMTPSA id 765F122B2D; Wed, 5 Feb 2014 04:17:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1391573830; bh=T5wBzZsDllFwc196k47nhJrBmX9at8ZMx+duwfuxtu8=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=IFivhN6xdI/KY/w5ZnCq3IDLONcYTSdWJaC0M5pkwZvuO9esnvPGU/5n63/O5cf1r HviP/p0dBUMeKjJfuVE1J0o0u/7VT0IZlC9XCTfd6GiTdeuAPOwS+q5KXpiVaD6bH1 26JXZL7nErwL2CSXpcpo/6tCeIyaz0rJDl5RHG0Y= Message-ID: <52F1BB42.7040307@dougbarton.us> Date: Tue, 04 Feb 2014 20:17:06 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Simon Perreault , Fernando Gont , Stephen Farrell , The IESG Subject: Re: Stephen Farrell's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS and COMMENT) References: <20140121155253.23475.70004.idtracker@ietfa.amsl.com> <52DE9E63.5050404@si6networks.com> <52DEA496.9000000@viagenie.ca> In-Reply-To: <52DEA496.9000000@viagenie.ca> X-Enigmail-Version: 1.6 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, Lloyd Wood , draft-ietf-6man-stable-privacy-addresses@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 04:17:15 -0000 On 01/21/2014 08:47 AM, Simon Perreault wrote: > On all the platforms I know there would be no practical reason to pick > MD5. Something better is always available and just as easy to use. I > don't want new code to use MD5 "because it was given as an example in > the RFC". Removing MD5 from the examples list would make me happy. +1 Also +1 on including HMAC-SHA1 and ideally HMAC-SHA256 as explicit examples. (This is all assuming the draft continues to advance. I continue to think it's at best a solution looking for a problem, and at worst a needless change that continues the harmful trend of fiddling with the spec long after we should have stopped.) Doug From fgont@si6networks.com Tue Feb 4 20:26:26 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C93F1A0021 for ; Tue, 4 Feb 2014 20:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xC_AR2ng_ud for ; Tue, 4 Feb 2014 20:26:23 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 966921A0020 for <6man@ietf.org>; Tue, 4 Feb 2014 20:26:23 -0800 (PST) Received: from [2001:5c0:1000:a::d7f] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WAu41-0000tY-LR; Wed, 05 Feb 2014 05:26:17 +0100 Message-ID: <52F1BD1F.2080007@si6networks.com> Date: Wed, 05 Feb 2014 01:25:03 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Suresh Krishnan , "6man@ietf.org" <6man@ietf.org>, "Will Liu (Shucheng)" , "C. M. Heard" Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <52F1B8CE.4070803@ericsson.com> In-Reply-To: <52F1B8CE.4070803@ericsson.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Tim Chown X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 04:26:26 -0000 Hi, Suresh, Thanks so much for your response! Please find my comments in-line... On 02/05/2014 01:06 AM, Suresh Krishnan wrote: > > "Yes we wanted to do this as well, but the WG didn't want to waste a > protocol number for something that may never be used" Short version of my response :-) : This seems to have happened two/three years ago... so it might be worthwhile to revisit that decision. In particular: 1) If this problem remains un-addressed, then it's impossible to differentiate between new upper-layer headers (e.g. a new transport protocol) and new extension headers. Since such new extension headers might be leveraged for malicious purposes, the end-result is that middle-boxes are going to block *everything* (see RFC7045), which means: + no new extension headers + no new transport protocols ... so I think we really don't want to go there. 2) Among the possible ways to solve this problem is to just use *a single* Next Header value -- which turns out how we both tried to solve separately (which is probably an indication that that's a sensible way to do it ;-) ). It doesn't seem too onerous to use a single Next Header value... particularly when the alternative is to implicitly waste all possible Next Header values (see above). 3) We really want to make the extension headers "workable" (RFC7045). Current stats seem to indicate that they are being massively dropped in the public Internet (see e.g. .. and Tim Chown's research show similar numbers). We either do something about it.. or else we'll have to completey forget about ext headers. > But unfortunately, it turns out that this was not really a problem the > WG wanted to solve with RFC6564 :-). :-) > I think Thomas Narten's comment summarized the wg feeling at the time > the best. > > "My general sense is that this work is mostly just good common sense > advice to someone who has a need to define a new extension type. But > until we see such a concrete proposal, I am not convinced (yet) that > we should define anything new that suggests people go change > implementations or allocate code points. Both are premature." The problem here is that unless we do something now, in the event someone needs to define a new extension header (or transport protocol!), it simply won't be possible. So, by doing nothing, we kind of are implicitly saying "No new extension headers, and no new transport protocols". *That's* really premature. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From dougb@dougbarton.us Tue Feb 4 20:37:39 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7948E1A0026 for ; Tue, 4 Feb 2014 20:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLxyOhHdmDB9 for ; Tue, 4 Feb 2014 20:37:35 -0800 (PST) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 923371A0024 for ; Tue, 4 Feb 2014 20:37:35 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:f5ba:4b6d:93ee:711a] (unknown [IPv6:2001:470:d:5e7:f5ba:4b6d:93ee:711a]) by dougbarton.us (Postfix) with ESMTPSA id 0B92722B2A for ; Wed, 5 Feb 2014 04:37:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1391575055; bh=kDevOQl7bq7dxz+T5oJV7vXIUOAfcMe62m1Z69CPoZ8=; h=Date:From:To:Subject:References:In-Reply-To; b=jBUx+UYIvimT7VCgqyfONAmH3QbH+fLQaBsZtMFLtwAcrNYhWigDzG2KclOyMUB70 hsniq8v6+drH1avOHFXF7hMpqA9cice0L5fmQUlpskPhglJ+3E+aGh+f9XX5uchmk5 GFplwX8/ZrPfh0GamhEdKbvfy7ElMIL9Zv8ZX6Sc= Message-ID: <52F1C00E.2050508@dougbarton.us> Date: Tue, 04 Feb 2014 20:37:34 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Reducing the battery impact of ND References: <52D96663.6060005@sonic.net> <52DA0ABA.8030903@acm.org> <52E03BB4.8040309@acm.org> In-Reply-To: X-Enigmail-Version: 1.6 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.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 04:37:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/22/2014 01:57 PM, Ole Troan wrote: | example: a host successfully does router discovery. RA lifetime is relatively short, e.g. 3 * router advertisement interval. | host doesn't receive any of the multicast RAs (network drops them or whatever). | | what would be the best behaviour for the end-user? | a) host sits quietly and waits for a periodic RA | b) host restarts the initial router discovery Clearly it's b, or was this a rhetorical question? Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBCAAGBQJS8cAOAAoJEFzGhvEaGryEB2sH/30cuUQoJv0MXdl7V1w1gvzH uZeGJWSApWOkxio4NYhtBsHnp1ICvi8z+xgIH2AVtR37eUXWZvmAFpLEm+jb2ikJ tB9etB7IT0ou+pYexkYbYbA+MQZfKrLi4agi2lciu94wOU9KkUKtljvEFXpaCCZf bZwEuNCpae74F1c+4M9NcXTy926OeDFfmkNa9HcfyKCnfJ0ubpdt5lpygQl/DmqV 7jQ9/z8IBVE3CDPm/lrEuyt5PgLGmXw+HtcXaTOnLFf3mfUUQ68JJZWGFbGhpTTg eH84z2DLrpxfXs9YqR8+JoeJ+lT2f7kzGnjARrCUwfReavRNtnm4C2kYExhxxPk= =K/3x -----END PGP SIGNATURE----- From brian.e.carpenter@gmail.com Wed Feb 5 16:50:27 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31DF1A0234 for ; Wed, 5 Feb 2014 16:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNIxDq7S2Ngg for ; Wed, 5 Feb 2014 16:50:24 -0800 (PST) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C9E941A0202 for ; Wed, 5 Feb 2014 16:50:24 -0800 (PST) Received: by mail-yh0-f45.google.com with SMTP id i57so1326137yha.32 for ; Wed, 05 Feb 2014 16:50:23 -0800 (PST) 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=UDYBTeFl/kXYvo0KgOC3Gp5X9tqyzpS0k9iqakaR81I=; b=tg54Wpi6/YB43F5e+FMD2XB29vp2SG43YE9/jrOgkqoEL5Tuk4FDMJIXgH6wByh8tx 3w+tBCYB2xGN/J052eiZAj+iF4P1yrF52TyB1GP77QRxdt3gni9R5O0T4wPXlzKpnQ/y J5eSwr8CXfWNFb0k9evWtYZqibl3JM/cELLDDPlYFb/1lIsJ/3F9T8PKhtmGZ5Hj6Ibd ChPEZpC7g12aIWImUTCV7ZAS1l7QFE6Lc4rnRh95Xnc/b7GngUCV4M+B5B/y3Hym9R59 fno7nYSrR/O0INmSti4g8EegmsoTA96K609nfznDl4y36KSHQe4svReZhDqy5C/88oMN E20w== X-Received: by 10.236.150.45 with SMTP id y33mr3620873yhj.124.1391647823891; Wed, 05 Feb 2014 16:50:23 -0800 (PST) Received: from [192.168.178.23] (80.199.69.111.dynamic.snap.net.nz. [111.69.199.80]) by mx.google.com with ESMTPSA id mo2sm80812875pbc.6.2014.02.05.16.50.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Feb 2014 16:50:23 -0800 (PST) Message-ID: <52F2DC55.5070200@gmail.com> Date: Thu, 06 Feb 2014 13:50:29 +1300 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-carpenter-6man-why64-01.txt] Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 00:50:27 -0000 Updated following comments on the previous version. This is still incomplete and we'd like to get more comments, by email or in London Brian -------- Original Message -------- Subject: I-D Action: draft-carpenter-6man-why64-01.txt Date: Wed, 05 Feb 2014 16:45:02 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis of the 64-bit Boundary in IPv6 Addressing Authors : Brian Carpenter Tim Chown Fernando Gont Sheng Jiang Alexandru Petrescu Andrew Yourtchenko Filename : draft-carpenter-6man-why64-01.txt Pages : 20 Date : 2014-02-05 Abstract: The IPv6 unicast addressing format includes a separation between the prefix used to route packets to a subnet and the interface identifier used to specify a given interface connected to that subnet. Historically the interface identifier has been defined as 64 bits long, leaving 64 bits for the prefix. This document discusses the reasons for this fixed boundary and the issues involved in treating it as a variable boundary. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-6man-why64/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-carpenter-6man-why64-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-carpenter-6man-why64-01 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 samita.chakrabarti@ericsson.com Wed Feb 5 19:57:40 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25EB1A0365 for ; Wed, 5 Feb 2014 19:57:40 -0800 (PST) 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=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DO3tvrXAWOW9 for ; Wed, 5 Feb 2014 19:57:38 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 50B121A0363 for ; Wed, 5 Feb 2014 19:57:38 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-7b-52f3082b1821 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 31.C8.11484.B2803F25; Thu, 6 Feb 2014 04:57:32 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0387.000; Wed, 5 Feb 2014 22:57:30 -0500 From: Samita Chakrabarti To: "Pascal Thubert (pthubert)" , Carsten Bormann Subject: RE: Reducing the battery impact of ND --> Problems with ND multicast Thread-Topic: Reducing the battery impact of ND --> Problems with ND multicast Thread-Index: Ac8i7uPla/9XE6YWQjay0j8vGecZpA== Date: Thu, 6 Feb 2014 03:57:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyuXRPrK4Ox+cgg1mdPBZHptxltXh59j2T xYwp7xgteu4tYXFg8ZjyeyOrx5IlP5k8FjyZy+YxbVFmAEsUl01Kak5mWWqRvl0CV8byWUkF vRYVT/pnsTcw3tbtYuTkkBAwkVixezcLhC0mceHeerYuRi4OIYEjjBIPXnWyQDjLGCV+bVvI DFLFJmAl0dG7hx3EFhEIk9hybTVYnFnAWeLa4XYwW1jAV2JdzxM2iJoAiS9Hp0LV60l8XtkF FmcRUJGYf6YDbDMvUP3JlxNYQWxGoCu+n1rDBDFTXOLWk/lMENcJSCzZc54ZwhaVePn4HyuE rSQxaek5Voh6PYkbU6ewQdjaEssWvmaGmC8ocXLmE5YJjCKzkIydhaRlFpKWWUhaFjCyrGLk KC1OLctNNzLcxAiMjWMSbI47GBd8sjzEKM3BoiTO++Wtc5CQQHpiSWp2ampBalF8UWlOavEh RiYOTqkGxhV9c3/PWfx6c5+XH1eeX832M/fYfTc32n/trzoZLrLt4Yanoqee/RSNKWq5+IKd /V2pt0NT5IWdP/vqE1RCuNgZ8rnK74u55kxZ+TdN6nU667Rn/6dKz4yeepGtZaF3gOqDszt/ 2Ce5+7ku4bF3lVO82LjJWvdDtlfF/9fbLgR0aEe1Vv0OU2Ipzkg01GIuKk4EAPdoU81bAgAA Cc: Thomas Watteyne , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 03:57:41 -0000 In order to provide more data on the problems with multicast on ND messages= and hacks from vendors independently, the following information may be hel= pful. I am sure the internet is running and there are not many IPv6 impleme= ntations out there, so it did not become a pain yet.=20 The problems are two fold 1) vendor proprietary solutions/hacks 2) interop= erability issues. That is apparent in Wifi-controller and AP situation whe= n the vendor specific hacks are only understood by the single vendor equipm= ents. =20 Here is an example of a problem case:=20 Router--->Wifi-Cotnroller--->AP--->UE/Host * Wifi-controller is sitting in a tree structure of AP and almost at the ro= ot of the tree. * The ND multicast messages are replicated via all physical and virtual po= rts. ARP and DHCPv4 broadcasts are also problematic. * This Wifi-controller normally handles both fixed and mobile traffic as we= ll.=20 * One Wifi-Controller can have up to a few thousand AP * Each AP can have up to several 100 Clients Depending on the capacity of Wifi-controller, the number of physical ports = and number of Aps could be large and they cannot tolerate periodic multicas= t or broadcast messages in order to maintain the delivery of user data.=20 Solution: Hack that works with one vendor's wifi-controller and APs. M2M nodes running IPv6: Let's assume that in 3GPP there was some information IETF guidance to stop = periodic RA, but if those devices move and go into a Wifi zone and are serv= ed by the wifi-Controller - the same wifi-controller and AP point problem a= rise. Of course vendors and operators are making things work with number of= hacks and perhaps that provide advantage of vendor locking or making diffe= rentiation in one's portfolio. M2M devices are large in number for one wifi-controller's domain. [ severa= l 100s to 1000s ] The registration method helps keeping track of the node at the router/switc= h level for providing services, security and perhaps that can be somehow us= eful for tying up with other kind of intelligent decisions in SDN environme= nt.=20 If IETF promotes interoperability and promotes improvement of the decades-o= ld protocol to work with needs for different usages of IPv6, I think effici= ent-nd offers solution for that. It may not be perfect today, but the quest= ion is to adopt the document and allow improvements.=20 To be honest, these problems are real and going through processes of writin= g up several documents before trying to solve a solution that has been impl= emented and proven in wireless networks will only make things worse.=20 -Samita -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Pascal Thubert (pthu= bert) Sent: Saturday, February 01, 2014 3:03 AM To: Carsten Bormann Cc: Thomas Watteyne; 6man WG Subject: Re: Reducing the battery impact of ND +1, Direct from an implementor of the hackery in question in widely distrib= uted switches and wireless controllers. Our first generation was really about protecting against rogues (SAVI, RA G= UARD). Interestingly, our second generation was focussed on multicast control to p= rotect the wireless medium (ND Suppression including RA throttling and ND p= roxy) to address customers and product management requests for the wifi mar= ket. Based on that support, I have developped a prototype backbone router that l= earns southwards from 6LoWPAN ND registration and proxies northwards classi= cal ND. 6TiSCH has planned a plugfest during the IETF and I hope we=B4ll be able to= demo this fonctionality at that time with real ipv6 motes. Cheers, Pascal > Le 1 f=E9vr. 2014 =E0 11:05, "Carsten Bormann" a =E9crit : >=20 > On 01 Feb 2014, at 08:49, Erik Nordmark wrote: >=20 >>> ... and can someone please remind me what exactly was wrong with ARP? O= ther than the fact that v4 uses it?! >=20 > What Erik said, plus maybe this reminder: >=20 > When ARP was invented more than 30 years ago, Ethernet networks were run = on the assumption that everyone on them could be trusted, both from a secur= ity and from an implementation bugs perspective. > (Those yellow-cable networks were so fragile... Let's not digress.) >=20 > To make ARP actually work in less peaceful environments, there is usually= significant hackery deployed at layer 2 (in Ethernet switches and WiFi bas= e stations/controllers). With all that hackery in place, it may *seem* as = if ARP works, but it is really the combination of the ARP implementation in= the IP nodes and the magic in the switches that makes this so. >=20 > ND inherited most of this situation, except that the hackery wasn't deplo= yed yet. That's why you hear so much about ND being "insecure", "not deplo= yable" - ND really is much better than ARP, it just had to wait for the hac= ks to catch up. The directed multicast of ND (as opposed to ARP's broadcas= t) only makes a difference where L2 actually implements that directionality= ; more hackery. (The irony is that MLD now becomes an address registration= protocol that is needed to make the illusion of "no registration" work at = the ND level, but I digress again.) >=20 > So the reality today is that we have this fragile combination of the docu= mented protocols and the switch vendor magic that makes it all work. Of co= urse, the switch vendors don't complain; it creates an opportunity for mark= et differentiation. >=20 > Now, for 6LoWPAN, we had to build something that relies much less on mult= icast. That became 6LoWPAN-ND, RFC 6775. Having built this fine hammer, o= f course other nails sprang to mind. The above situation looks like a fine= nail to me (except that legacy compatibility makes things so much more com= plex). That's maybe the explanation why this discussion didn't start with = documenting the well-known problems, but with looking at one specific solut= ion, and how it could be made to work with legacy. But I agree documenting= the problem would be a worthwhile exercise, if it is not used as an excuse= to stop looking for solutions. >=20 > Clearly, efficient-ND will work best if it doesn't require a new layer of= L2 hackery, and if it cooperates reasonable with (or works around) the exi= sting, deployed hackery. This is more work to make sure given that this ha= ckery is only partially documented. So that is maybe another reason to wor= k on documenting ARP/ND's problems and the existing magic. >=20 > Gr=FC=DFe, Carsten >=20 > -------------------------------------------------------------------- > 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 wwwrun@rfc-editor.org Thu Feb 6 02:00:19 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5001A00B0 for ; Thu, 6 Feb 2014 02:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.953 X-Spam-Level: X-Spam-Status: No, score=0.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVN1Q6HQcNpz for ; Thu, 6 Feb 2014 02:00:17 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id C2F6F1A00A9 for ; Thu, 6 Feb 2014 02:00:17 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 9F25D7FC158; Thu, 6 Feb 2014 02:00:13 -0800 (PST) To: kawamucho@mesh.ad.jp, kawashimam@vx.jp.nec.com, brian@innovationslab.net, ted.lemon@nominum.com, bob.hinden@gmail.com, otroan@employees.org Subject: [Technical Errata Reported] RFC5952 (3884) From: RFC Errata System Message-Id: <20140206100013.9F25D7FC158@rfc-editor.org> Date: Thu, 6 Feb 2014 02:00:13 -0800 (PST) Cc: rfc-editor@rfc-editor.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 10:00:19 -0000 The following errata report has been submitted for RFC5952, "A Recommendation for IPv6 Address Text Representation". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5952&eid=3884 -------------------------------------- Type: Technical Reported by: Richard Hartmann Section: 4.2.2. Original Text ------------- 4.2.2. Handling One 16-Bit 0 Field The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field. For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but 2001:db8::1:1:1:1:1 is not correct. Corrected Text -------------- 4.2.2. Incorrect use of "::" The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field. For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but 2001:db8::1:1:1:1:1 is not correct. The symbol "::" MUST NOT be used just so. For example, the representation 2001:db8:1:1:1:1:1:1 is correct, but 2001:db8:1:1::1:1:1:1 is not correct. Notes ----- You would think this should be obvious, but I have seen actual discussions that 2001:db8:1:1::1:1:1:1 is correct syntax. Explicitly forbidding this form does no harm and stops all discussions in this direction. Thanks for your work. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5952 (draft-ietf-6man-text-addr-representation-07) -------------------------------------- Title : A Recommendation for IPv6 Address Text Representation Publication Date : August 2010 Author(s) : S. Kawamura, M. Kawashima Category : PROPOSED STANDARD Source : IPv6 Maintenance Area : Internet Stream : IETF Verifying Party : IESG From samita.chakrabarti@ericsson.com Thu Feb 6 02:05:41 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365A91A0200 for ; Thu, 6 Feb 2014 02:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lc7tUtp5doqr for ; Thu, 6 Feb 2014 02:05:37 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3F61A00B4 for <6man@ietf.org>; Thu, 6 Feb 2014 02:05:37 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-7b-52f35e6b53e7 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id CD.EB.12743.B6E53F25; Thu, 6 Feb 2014 11:05:32 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 05:05:34 -0500 From: Samita Chakrabarti To: "6man@ietf.org" <6man@ietf.org> Subject: Summary of comments from adoption call of draft-chakrabarti-nordmark-6man-efficient-nd-04 Thread-Topic: Summary of comments from adoption call of draft-chakrabarti-nordmark-6man-efficient-nd-04 Thread-Index: Ac8jIawi+/whl9UMT0+WgG8z+vQ/5g== Date: Thu, 6 Feb 2014 10:05:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_ECA43DA70480A3498E43C3471FB2E1F01C15D78Feusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyuXSPt25O3OcggydzRSwWdDaxWqxccZfJ gcljyZKfTB5fLn9mC2CK4rJJSc3JLEst0rdL4Mo4/qmDpaDtLmPFkqfHGRsY51xn7GLk5JAQ MJGY0/mIHcIWk7hwbz1bFyMXh5DAEUaJXZcPMYEkhASWMUq8uxMOYrMJWEl09O4BaxARUJZo O3oErIZZwFvixeO/bCC2sECKRPe5RlaImkyJe5/usEHYehJvPxxi7mLk4GARUJH49LQMJMwr 4CvxbPdvsBJGoBu+n1oDNVJc4taT+UwQtwlILNlznhnCFpV4+fgfK4StJDFp6TlWkJHMAvkS P69EQYwUlDg58wnLBEbhWUgmzUKomoWkCiKsKbF+lz5EtaLElO6H7BC2hkTrnLnsyOILGNlX MXKUFqeW5aYbGWxiBEbIMQk23R2Me15aHmKU5mBREuf98tY5SEggPbEkNTs1tSC1KL6oNCe1 +BAjEwenVANjzAan0243JXS2p28xuRjEYPe1n2vGzzyXD0aLXc0OT/A9pBm9rmLHWks+rhZW caHVz9Q3uitOMDbIXpBl3MZT7cwubrV9xzTJttsy+kG/dpn9jPfbKbF8Q3H/syYVvwVvxK2D OGa/Kc8VMOkQvXxlTpvK98Cs8KAYzV6d2zdVmY4/ee2j+UGJpTgj0VCLuag4EQCN4KLiXgIA AA== Cc: "6man Chairs \(6man-chairs@tools.ietf.org\)" <6man-chairs@tools.ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 10:05:41 -0000 --_000_ECA43DA70480A3498E43C3471FB2E1F01C15D78Feusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIZWxsbyBBbGw6DQoNCldlIGhhdmUgIGhhZCAgbGl2ZWx5IGFuZCBpbnRlcmVzdGluZyBkaXNj dXNzaW9ucyBvbiB0aGUgbWFpbGluZyBsaXN0IG9uICBlZmZpY2llbnQtbmQuDQoNCkhlcmUgaXMg YSAgc3VtbWFyeSBnYXRoZXJlZCBmcm9tIHZhcmlvdXMgZGlzY3Vzc2lvbiB0aHJlYWRzOg0KDQpB cyBvZiBKYW51YXJ5IDE1LCAyMDE0IG9uIHRoZSBhZG9wdGlvbiBjYWxsLCBoZXJlIGFyZSBzb21l IG51bWJlcnM6DQoNCjEuICAgICAgIFN1cHBvcnQgKDEwIGluY2x1ZGluZyBjby1hdXRob3JzKQ0K DQoyLiAgICAgICBObyBzdXBwb3J0IG9yIG5vIG5lZWQgb2Ygc3VjaCB3b3JrICgzKQ0KDQozLiAg ICAgICBDb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgIGZvciB1cGRhdGVzICg0KSBbIEVyaWMgVnlu Y2tlLCBBbmRyZXcgWSwgTWFyayBaWlosIE1pY2hhZWwgQWJyYWhhbXNvbl0NCg0KDQoNCkluIGdl bmVyYWwgOiBCZXR0ZXIgcHJvYmxlbSBzdGF0ZW1lbnQgYW5kIHNpbXBsaWZpY2F0aW9uL2NsYXJp ZmljYXRpb24vaW1wcm92ZW1lbnQgaXMgbmVlZGVkLiBUaGVyZSBhcmUgbXVsdGlwbGUgZm9sa3Mg d2hvIGNvbW1lbnRlZCB0aGF0IHN1Y2ggd29yayBpcyBuZWVkZWQuDQoNCg0KDQpEcmFmdC1pZXRm LTZtYW4tcmVzaWxpZW50LXJzIGNvbnRleHQ6DQpJdCBpbiBmYWN0IGhhcyAgYSBkaWZmZXJlbnQg c2NvcGUgdGhhdCAgc3VnZ2VzdHMgaW5jcmVhc2luZyAgdGhlIHNvbGljaXRlZCBSUyBpbiBvcmRl ciB0byBjb25maWd1cmUgdGhlIGhvc3RzIHJlbGlhYmx5LiBSZXNpbGllbnQgUlMgaGFzIGFjY29t cGxpc2hlZCBpdHMgZ29hbCB3aXRoaW4gdGhlIHNjb3BlIG9mIHRoZSBwcm9ibGVtIHN0YXRlbWVu dA0KDQotICAgICAgICAgIEEgc3VnZ2VzdGlvbiB3YXMgbWFkZSB0byBpbmNyZWFzZSBpdHMgc2Nv cGUgd2hpY2ggcmVhbGx5IHN0ZXBzIGludG8gdGhlIHNjb3BlL3NvbHV0aW9uIGRlZmluZWQgaW4g ZHJhZnQtY2hha3JhYmFydGktbm9yZG1hcmstNm1hbi1lZmZpY2llbnQtbmQgYW5kIHRodXMgd2Fz IG9iamVjdGVkIGJ5IHRoZSBjby1hdXRob3JzIG9mIGVmZmljaWVudC1uZA0KDQotICAgICAgICAg IEEgc3VnZ2VzdGlvbiB3YXMgbWFkZSB0aGF0IGFsbCBob3N0cyBzaG91bGQgc2VuZCBwZXJpb2Rp YyBSUyBhcyBhbiBhbHRlcm5hdGl2ZSB0byBwZXJpb2RpYyBSQSDigJMgdGhhdCBkb2VzIG5vdCB3 b3JrIGFuZCBzZXZlcmFsIGNvbmNlcm5zIHdlcmUgcmFpc2VkIG9uIHRheGluZyBob3N0cyB3aXRo IGJhdHRlcnkgcG93ZXINCg0KDQpORCBhbmQgYmF0dGVyeSBwb3dlciBpc3N1ZTogWyBha2EgbmVl ZCBmb3Igc3VjaCB3b3JrP10NCg0KDQoxKSAgICAgIFNwb250YW5lb3VzIGFsbC1ob3N0cyBtdWx0 aWNhc3RzIGludGVyZmVyZSB3aXRoIHRoZXNlIG1lY2hhbmlzbXMsIHRodXMgdGhlIGJhdHRlcnkg ZHJhaW4gb24gdGhlIGRldmljZXMgaXMgbXVjaCBoaWdoZXIgLSBlc3BlY2lhbGx5IGluIGEgdHlw aWNhbCBuZXR3b3JrIHdoZXJlIHRoZSBtb2JpbGUgZGV2aWNlcyBtb3ZlLCBhbmQgbWlnaHQgdHJp Z2dlciBhbiBSUy9SQSBvbiBlYWNoIEwyIHJvYW0gYmV0d2VlbiBCU1NJRHMNCg0KMikgICAgICBB UlAgaW4gSVB2NCBoYWQgc2ltaWxhciBpc3N1ZXMgd2l0aCBicm9hZGNhc3QsIE5EIHRyaWVkIHRv IHNvbHZlIHRoYXQgd2l0aCBkaXJlY3RlZCBtdWx0aWNhc3QgdGhhdCBkZXBlbmRzIG9uIEwyIHRl Y2hub2xvZ2llcyBhbmQgd29ya3Mgb24gZml4ZWQgRXRoZXJuZXQuIEJ1dCBib3RoIEFSUCBicm9h ZGNhc3RzIGFuZCBORCBtdWx0aWNhc3RzIGFyZSB0cmVhdGVkIGVxdWFsbHkgaW4gbWFueSB3aXJl bGVzcyBlbnZpcm9ubWVudHMgd2hlcmUgTDItZHJpdmVycyBkb27igJl0IHN1cHBvcnQgbXVsdGlj YXN0IHJlc3VsdGluZyBpbiBodWdlIHNpZ25hbGluZyBpbiB0aGUgbmV0d29yayBhbmQgd2FzdGlu ZyBiYXR0ZXJ5IHBvd2VyIG9mIHRoZSBob3N0c1sgbW9iaWxlIGRldmljZXMsIGludGVybmV0IG9m IFRoaW5ncywgd2lyZWxlc3Mgc3dpdGNoZXMgZXRjLiBdDQoNCjMpICAgICAgTWFueSB3aXJlbGVz cyBzd2l0Y2hlcyBhbmQgd2lmaS1jb250cm9sbGVycyBhbmQgQVAgbWl0aWdhdGUgdGhlIE5EIGFu ZCBBUlAgcmVsYXRlZCBmbG9vZGluZyBbIG5vdCBhbGwgc3dpdGNoZXMsIEFQIGltcGxlbWVudCBN TEQgc25vb3BpbmddIGJ5IHByb3ZpZGluZyBwcm9wcmlldGFyeSBzb2x1dGlvbnMgd2hpY2ggcmVz dWx0IGluIHZlbmRvciBzcGVjaWZpYyBub24taW50ZXJvcGVyYWJsZSBJUHY2IHNvbHV0aW9ucyBp biB0aGUgbmV0d29yayBlbHNlIGl0IHByZXZlbnRzIGRlcGxveW1lbnQgb2Ygc3VjY2Vzc2Z1bCBJ UHY2Lg0KDQoNClN1bW1hcnkgb2YgdGVjaG5pY2FsIGNoYW5nZXMgcmVxdWVzdGVkIGJ5IHRoZSBy ZXZpZXdlcnMgb2YgZWZmaWNpZW50LW5kOg0KQ2xhcmlmeSBwcm9ibGVtIHN0YXRlbWVudCB3aXRo IG1vcmUganVzdGlmaWNhdGlvbiBvZiB0aGUgaXNzdWVzIHdpdGggbXVsdGljYXN0IGFuZCB3aHkg cmVnaXN0cmF0aW9uIGlzIG5lZWRlZA0K74K3IENsYXJpZnkgd2hldGhlciB0aGlzIGRyYWZ0IHdp bGwgc3VwcG9ydCBkcmFmdC1nb250LTZtYW4tZGVwcmVjYXRlLWV1aTY0LWJhc2VkLWFkZHJlc3Nl cy0wMA0K74K3IERyYWZ0IHJlZmVycyB0byBFVUktNjQgYmFzZWQgSVB2Ni1hZGRyZXNzZXMgYW5k IDY0Yml0IE1BQyBhZGRyZXNzIOKAkyBOZWVkcyB0byBmaXggdGhpcyB0byBzdGF0ZSBzdXBwb3J0 IGZvciA0OGJpdCBNQUMgYWRkcmVzcyBhbmQgbm9uLUVVSS02NCBiYXNlZCBJUHY2IGFkZHJlc3MN Cu+CtyBDbGFyaWZ5IGJvb3RzdHJhcHBpbmcgYW5kIERBRCBmb3IgbGluay1sb2NhbCBvciBub3Qg SG93IHRvIGluZm9ybSBkdXBsaWNhdGUgYWRkcmVzcyBkZXRlY3Rpb24gZHVyaW5nIGxpbmstbG9j YWwgYWRkcmVzcyBmb3JtYXRpb24NCu+CtyBDbGFyaWZ5IG1vcmUgb24gY28tZXhpc3RlbmNlIHdp dGggdGhlIGxlZ2FjeSBtb2RlbCwgZGlzdHJpYnV0aW9uIHNjaGVtZSBvZiB0aGUgYWRkcmVzc2Vz IChoaWVyYXJjaGljYWwsIGhhc2gtYmFzZWQsIMWgKSwgbmF0dXJlIG9mIHRoZSByZWdpc3RyYXJz IChSb3V0ZXJzPyBTd2l0Y2hlcz8gREhDUCBzZXJ2ZXJzPyDFoCkuDQrvgrcgQ29uc2lkZXIgTWlr YWVs4oCZcyBzdWdnZXN0aW9uIG9uIHVzaW5nIERIQ1B2Nl9JQV9OQSBvcHRpb24gdG8gaW50ZXJh Y3Qgd2l0aCBhIERIQ1B2NiBzZXJ2ZXIgWyBFQUggaW50ZXJhY3Rpbmcgd2l0aCBhIERIQ1B2NiBz ZXJ2ZXJdDQrvgrcgRGVzY3JpYmUgYmVoYXZpb3IgL2ludGVyYWN0aW9uIHdpdGggVlJSUCBhbmQg aG93IGRvIHdlIGRlYWwgd2l0aCBzaW5nbGUgcG9pbnQgb2YgZmFpbHVyZSBzaG91bGQgdGhlcmUg YmUgc2luZ2xlIGRlZmF1bHQgcm91dGVyIGluIHRoZSBsaW5rDQrvgrcgRXhwbGFpbiB3aGV0aGVy IHRoaXMgZHJhZnQgcmVhbGx5IGlzIGxpbWl0ZWQgdG8gb25lIGNlbnRyYWwgcG9pbnQgYm90dGxl bmVjayBvciBpdCBjYW4gaGFuZGxlIHNpbmdsZSBwb2ludCBvZiBmYWlsdXJlIGdyYWNlZnVsbHkg d2l0aCBtdWx0aXBsZSBkZWZhdWx0IHJvdXRlcnMNCu+CtyBSZW1vdmUgdGhlIHVzZSBjYXNlcw0K DQpUaGFua3MsDQotU2FtaXRhDQoNCi0NCg== --_000_ECA43DA70480A3498E43C3471FB2E1F01C15D78Feusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3Qg bDANCgl7bXNvLWxpc3QtaWQ6ODI0MjAwNTYyOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczotMTE0Mzk0OTk1NiA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcx NSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9 DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2 ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQt aW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo5MjM1Mzc1Njk7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi03NzA5MjU2OTggLTE0 MzIzMjc0ODAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2 OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVm dDoyMC4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3Qg bDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo1Ni4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJn aW4tbGVmdDo5Mi4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEyOC4yNXB0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgltYXJnaW4tbGVmdDoxNjQuMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6 MjAwLjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjM2LjI1cHQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1h cmdpbi1sZWZ0OjI3Mi4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozMDguMjVw dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwyDQoJe21zby1saXN0LWlkOjEzMjk1NTU1NjA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOjIxMTk4Njk1MTAgNjc2OTg3MDUgNjc2OTg3MTMgNjc2OTg3 MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7 fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5k ZW50Oi05LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0K QGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1i b3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGVsbG8gQWxsOjxv OnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5XZSBoYXZlJm5ic3A7IGhhZCZuYnNw OyBsaXZlbHkgYW5kIGludGVyZXN0aW5nIGRpc2N1c3Npb25zIG9uIHRoZSBtYWlsaW5nIGxpc3Qg b24gJm5ic3A7ZWZmaWNpZW50LW5kLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhlcmUgaXMgYSAmbmJzcDtzdW1tYXJ5IGdh dGhlcmVkIGZyb20gdmFyaW91cyBkaXNjdXNzaW9uIHRocmVhZHM6PG86cD48L286cD48L3NwYW4+ PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QXMgb2YgSmFu dWFyeSAxNSwgMjAxNCBvbiB0aGUgYWRvcHRpb24gY2FsbCwgaGVyZSBhcmUgc29tZSBudW1iZXJz OjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwh W2lmICFzdXBwb3J0TGlzdHNdPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48L2k+PC9iPjwhW2VuZGlmXT48Yj48aT48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+U3VwcG9ydCAoMTAgaW5jbHVkaW5nIGNvLWF1dGhvcnMpPG86 cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYg IXN1cHBvcnRMaXN0c10+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvaT48L2I+PCFbZW5kaWZdPjxiPjxpPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5ObyBzdXBwb3J0IG9yIG5vIG5lZWQgb2Ygc3VjaCB3b3JrICgzKTxv OnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4zLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48L2k+PC9iPjwhW2VuZGlmXT48Yj48aT48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+Q29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zICZuYnNwO2ZvciB1cGRh dGVzICg0KSBbIEVyaWMgVnluY2tlLCBBbmRyZXcgWSwgTWFyayBaWlosIE1pY2hhZWwgQWJyYWhh bXNvbl08bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PGI+PGk+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkluIGdlbmVyYWwgOiBCZXR0ZXIgcHJvYmxlbSBz dGF0ZW1lbnQgYW5kIHNpbXBsaWZpY2F0aW9uL2NsYXJpZmljYXRpb24vaW1wcm92ZW1lbnQgaXMg bmVlZGVkLiBUaGVyZSBhcmUgbXVsdGlwbGUgZm9sa3Mgd2hvIGNvbW1lbnRlZCB0aGF0IHN1Y2gg d29yayBpcyBuZWVkZWQuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv aT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPkRyYWZ0LWlldGYtNm1hbi1yZXNpbGllbnQtcnMgY29udGV4dDo8bzpwPjwvbzpw Pjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5JdCBpbiBmYWN0IGhhcyAmbmJzcDthIGRpZmZlcmVudCBzY29w ZSB0aGF0ICZuYnNwO3N1Z2dlc3RzIGluY3JlYXNpbmcgJm5ic3A7dGhlIHNvbGljaXRlZCBSUyBp biBvcmRlciB0byBjb25maWd1cmUgdGhlIGhvc3RzIHJlbGlhYmx5LiBSZXNpbGllbnQgUlMgaGFz IGFjY29tcGxpc2hlZCBpdHMgZ29hbCB3aXRoaW4gdGhlIHNjb3BlIG9mIHRoZSBwcm9ibGVtIHN0 YXRlbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMC4yNXB0O3RleHQtaW5kZW50Oi0uMjVpbjtt c28tbGlzdDpsMSBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkEgc3Vn Z2VzdGlvbiB3YXMgbWFkZSB0byBpbmNyZWFzZSBpdHMgc2NvcGUgd2hpY2ggcmVhbGx5IHN0ZXBz IGludG8gdGhlIHNjb3BlL3NvbHV0aW9uIGRlZmluZWQgaW4gZHJhZnQtY2hha3JhYmFydGktbm9y ZG1hcmstNm1hbi1lZmZpY2llbnQtbmQgYW5kIHRodXMgd2FzIG9iamVjdGVkIGJ5IHRoZSBjby1h dXRob3JzIG9mIGVmZmljaWVudC1uZDxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMC4yNXB0O3RleHQt aW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPkEgc3VnZ2VzdGlvbiB3YXMgbWFkZSB0aGF0IGFsbCBob3N0cyBzaG91bGQgc2Vu ZCBwZXJpb2RpYyBSUyBhcyBhbiBhbHRlcm5hdGl2ZSB0byBwZXJpb2RpYyBSQSDigJMgdGhhdCBk b2VzIG5vdCB3b3JrIGFuZCBzZXZlcmFsIGNvbmNlcm5zIHdlcmUgcmFpc2VkIG9uIHRheGluZyBo b3N0cyB3aXRoIGJhdHRlcnkgcG93ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjAuMjVwdCI+PGI+ PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv aT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPk5EIGFuZCBiYXR0ZXJ5IHBvd2VyIGlzc3VlOiBbIGFrYSBuZWVkIGZvciBzdWNo IHdvcms/XTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0 LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzMiPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj4xKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwv c3Bhbj48L2k+PC9iPjwhW2VuZGlmXT48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ U3BvbnRhbmVvdXMgYWxsLWhvc3RzIG11bHRpY2FzdHMgaW50ZXJmZXJlIHdpdGggdGhlc2UgbWVj aGFuaXNtcywgdGh1cyB0aGUgYmF0dGVyeSBkcmFpbiBvbiB0aGUgZGV2aWNlcyBpcyBtdWNoIGhp Z2hlciAtIGVzcGVjaWFsbHkgaW4gYSB0eXBpY2FsIG5ldHdvcmsgd2hlcmUgdGhlIG1vYmlsZSBk ZXZpY2VzIG1vdmUsDQogYW5kIG1pZ2h0IHRyaWdnZXIgYW4gUlMvUkEgb24gZWFjaCBMMiByb2Ft IGJldHdlZW4gQlNTSURzPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMiBs ZXZlbDEgbGZvMyI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIpPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvaT48L2I+PCFbZW5kaWZdPjxiPjxp PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5BUlAgaW4gSVB2NCBoYWQgc2ltaWxhciBpc3N1 ZXMgd2l0aCBicm9hZGNhc3QsIE5EIHRyaWVkIHRvIHNvbHZlIHRoYXQgd2l0aCBkaXJlY3RlZCBt dWx0aWNhc3QgdGhhdCBkZXBlbmRzIG9uIEwyIHRlY2hub2xvZ2llcyBhbmQgd29ya3Mgb24gZml4 ZWQgRXRoZXJuZXQuIEJ1dCBib3RoIEFSUCBicm9hZGNhc3RzIGFuZCBORA0KIG11bHRpY2FzdHMg YXJlIHRyZWF0ZWQgZXF1YWxseSBpbiBtYW55IHdpcmVsZXNzIGVudmlyb25tZW50cyB3aGVyZSBM Mi1kcml2ZXJzIGRvbuKAmXQgc3VwcG9ydCBtdWx0aWNhc3QgcmVzdWx0aW5nIGluIGh1Z2Ugc2ln bmFsaW5nIGluIHRoZSBuZXR3b3JrIGFuZCB3YXN0aW5nIGJhdHRlcnkgcG93ZXIgb2YgdGhlIGhv c3RzWyBtb2JpbGUgZGV2aWNlcywgaW50ZXJuZXQgb2YgVGhpbmdzLCB3aXJlbGVzcyBzd2l0Y2hl cyBldGMuIF08bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwyIGxldmVsMSBs Zm8zIj48IVtpZiAhc3VwcG9ydExpc3RzXT48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Myk8c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9pPjwvYj48IVtlbmRpZl0+PGI+PGk+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk1hbnkgd2lyZWxlc3Mgc3dpdGNoZXMgYW5kIHdpZmktY29u dHJvbGxlcnMgYW5kIEFQIG1pdGlnYXRlIHRoZSBORCBhbmQgQVJQIHJlbGF0ZWQgZmxvb2Rpbmcg WyBub3QgYWxsIHN3aXRjaGVzLCBBUCBpbXBsZW1lbnQgTUxEIHNub29waW5nXSBieSBwcm92aWRp bmcgcHJvcHJpZXRhcnkgc29sdXRpb25zIHdoaWNoIHJlc3VsdA0KIGluIHZlbmRvciBzcGVjaWZp YyBub24taW50ZXJvcGVyYWJsZSBJUHY2IHNvbHV0aW9ucyBpbiB0aGUgbmV0d29yayBlbHNlIGl0 IHByZXZlbnRzIGRlcGxveW1lbnQgb2Ygc3VjY2Vzc2Z1bCBJUHY2LjxvOnA+PC9vOnA+PC9zcGFu PjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlN1bW1hcnkgb2YgdGVjaG5pY2FsIGNoYW5nZXMg cmVxdWVzdGVkIGJ5IHRoZSByZXZpZXdlcnMgb2YgZWZmaWNpZW50LW5kOjxvOnA+PC9vOnA+PC9z cGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPkNsYXJpZnkgcHJvYmxlbSBzdGF0ZW1lbnQgd2l0aCBtb3JlIGp1c3Rp ZmljYXRpb24gb2YgdGhlIGlzc3VlcyB3aXRoIG11bHRpY2FzdCBhbmQgd2h5IHJlZ2lzdHJhdGlv biBpcyBuZWVkZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj7vgrcgQ2xhcmlmeSB3aGV0 aGVyIHRoaXMgZHJhZnQgd2lsbCBzdXBwb3J0IGRyYWZ0LWdvbnQtNm1hbi1kZXByZWNhdGUtZXVp NjQtYmFzZWQtYWRkcmVzc2VzLTAwPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+74K3IERy YWZ0IHJlZmVycyB0byBFVUktNjQgYmFzZWQgSVB2Ni1hZGRyZXNzZXMgYW5kIDY0Yml0IE1BQyBh ZGRyZXNzIOKAkyBOZWVkcyB0byBmaXggdGhpcyB0byBzdGF0ZSBzdXBwb3J0IGZvciA0OGJpdCBN QUMgYWRkcmVzcyBhbmQgbm9uLUVVSS02NCBiYXNlZCBJUHY2IGFkZHJlc3M8bzpwPjwvbzpwPjwv c3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj7vgrcgQ2xhcmlmeSBib290c3RyYXBwaW5nIGFuZCBEQUQgZm9yIGxp bmstbG9jYWwgb3Igbm90IEhvdyB0byBpbmZvcm0gZHVwbGljYXRlIGFkZHJlc3MgZGV0ZWN0aW9u IGR1cmluZyBsaW5rLWxvY2FsIGFkZHJlc3MgZm9ybWF0aW9uPG86cD48L286cD48L3NwYW4+PC9p PjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+74K3IENsYXJpZnkgbW9yZSBvbiBjby1leGlzdGVuY2Ugd2l0aCB0aGUgbGVnYWN5 IG1vZGVsLCBkaXN0cmlidXRpb24gc2NoZW1lIG9mIHRoZSBhZGRyZXNzZXMgKGhpZXJhcmNoaWNh bCwgaGFzaC1iYXNlZCwgxaApLCBuYXR1cmUgb2YgdGhlIHJlZ2lzdHJhcnMgKFJvdXRlcnM/IFN3 aXRjaGVzPyBESENQIHNlcnZlcnM/IMWgKS48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj7v grcgQ29uc2lkZXIgTWlrYWVs4oCZcyBzdWdnZXN0aW9uIG9uIHVzaW5nIERIQ1B2Nl9JQV9OQSBv cHRpb24gdG8gaW50ZXJhY3Qgd2l0aCBhIERIQ1B2NiBzZXJ2ZXIgWyBFQUggaW50ZXJhY3Rpbmcg d2l0aCBhIERIQ1B2NiBzZXJ2ZXJdPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+74K3IERl c2NyaWJlIGJlaGF2aW9yIC9pbnRlcmFjdGlvbiB3aXRoIFZSUlAgYW5kIGhvdyBkbyB3ZSBkZWFs IHdpdGggc2luZ2xlIHBvaW50IG9mIGZhaWx1cmUgc2hvdWxkIHRoZXJlIGJlIHNpbmdsZSBkZWZh dWx0IHJvdXRlciBpbiB0aGUgbGluazxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPu+CtyBF eHBsYWluIHdoZXRoZXIgdGhpcyBkcmFmdCByZWFsbHkgaXMgbGltaXRlZCB0byBvbmUgY2VudHJh bCBwb2ludCBib3R0bGVuZWNrIG9yIGl0IGNhbiBoYW5kbGUgc2luZ2xlIHBvaW50IG9mIGZhaWx1 cmUgZ3JhY2VmdWxseSB3aXRoIG11bHRpcGxlIGRlZmF1bHQgcm91dGVyczxvOnA+PC9vOnA+PC9z cGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPu+CtyBSZW1vdmUgdGhlIHVzZSBjYXNlcyA8bzpwPg0KPC9vOnA+PC9z cGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5r cyw8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4tU2FtaXRhPG86cD48L286cD48L3NwYW4+ PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjIwLjI1cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4N CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48Yj48aT48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwv Yj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_ECA43DA70480A3498E43C3471FB2E1F01C15D78Feusaamb103erics_-- From narten@us.ibm.com Thu Feb 6 04:22:03 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA6E1A03B7 for ; Thu, 6 Feb 2014 04:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.436 X-Spam-Level: X-Spam-Status: No, score=-7.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TErpSTU9wZRE for ; Thu, 6 Feb 2014 04:22:01 -0800 (PST) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by ietfa.amsl.com (Postfix) with ESMTP id 410B21A03C9 for <6man@ietf.org>; Thu, 6 Feb 2014 04:22:01 -0800 (PST) Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <6man@ietf.org> from ; Thu, 6 Feb 2014 05:22:00 -0700 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e39.co.us.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 6 Feb 2014 05:21:58 -0700 Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id A1EA519D8042 for <6man@ietf.org>; Thu, 6 Feb 2014 05:21:57 -0700 (MST) Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by b03cxnp08026.gho.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s16CLcI71114474 for <6man@ietf.org>; Thu, 6 Feb 2014 13:21:38 +0100 Received: from d03av05.boulder.ibm.com (localhost [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s16CLuVr031369 for <6man@ietf.org>; Thu, 6 Feb 2014 05:21:57 -0700 Received: from cichlid.raleigh.ibm.com (dyn9050017179.mts.ibm.com [9.50.17.179] (may be forged)) by d03av05.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s16CLt48031318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Feb 2014 05:21:56 -0700 Received: from cichlid.raleigh.ibm.com.us.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id s16CLn2u020722; Thu, 6 Feb 2014 07:21:50 -0500 Date: Thu, 06 Feb 2014 07:21:49 -0500 Message-ID: From: Thomas Narten To: Fernando Gont Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers In-Reply-To: <52F1BD1F.2080007@si6networks.com> References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <52F1B8CE.4070803@ericsson.com> <52F1BD1F.2080007@si6networks.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/23.1 (x86_64-redhat-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14020612-9332-0000-0000-000003042A7D Cc: "C. M. Heard" , Tim Chown , "6man@ietf.org" <6man@ietf.org>, Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 12:22:03 -0000 At Wed, 05 Feb 2014 01:25:03 -0300, Fernando Gont wrote: > 1) If this problem remains un-addressed, then it's impossible to > differentiate between new upper-layer headers (e.g. a new transport > protocol) and new extension headers. Since such new extension headers > might be leveraged for malicious purposes, the end-result is that > middle-boxes are going to block *everything* (see RFC7045), which means: > > + no new extension headers > + no new transport protocols > > ... so I think we really don't want to go there. But we are already there. Folk won't deploy anything other than TCP/UDP because NAT won't deal with it. That has already been reality and is the reason that other or new transport protocols appear to be virtually undeployable today. Reality is that existing middleboxes tend to process what they understand and have been explicitely coded to deal with. They just punt on anything else because that is the easiest/safest thing to do. I see little that we can do to change that. Thomas From fgont@si6networks.com Thu Feb 6 04:47:16 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBCA1A03AF for ; Thu, 6 Feb 2014 04:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 741BWpl-8JjE for ; Thu, 6 Feb 2014 04:47:13 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id A59EE1A00F5 for <6man@ietf.org>; Thu, 6 Feb 2014 04:47:13 -0800 (PST) Received: from [2001:5c0:1400:a::be3] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WBOM8-0006yR-9v; Thu, 06 Feb 2014 13:47:00 +0100 Message-ID: <52F383A0.7030002@si6networks.com> Date: Thu, 06 Feb 2014 09:44:16 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Thomas Narten Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <52F1B8CE.4070803@ericsson.com> <52F1BD1F.2080007@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "C. M. Heard" , Tim Chown , "6man@ietf.org" <6man@ietf.org>, Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 12:47:16 -0000 Hi, Thomas, On 02/06/2014 09:21 AM, Thomas Narten wrote: >> 1) If this problem remains un-addressed, then it's impossible to >> differentiate between new upper-layer headers (e.g. a new transport >> protocol) and new extension headers. Since such new extension headers >> might be leveraged for malicious purposes, the end-result is that >> middle-boxes are going to block *everything* (see RFC7045), which means: >> >> + no new extension headers >> + no new transport protocols >> >> ... so I think we really don't want to go there. > > But we are already there. Folk won't deploy anything other than > TCP/UDP because NAT won't deal with it. That has already been reality > and is the reason that other or new transport protocols appear to be > virtually undeployable today. Well, IPv6 *might* give a fresh start in this respect -- there *might* be IPv6 NAT.. but not necessarily. So.. while the end result might be the same, it need not. I don't think we have widespread deployment of IPv6 NAT ("as we know it" for IPv4), nor that we have such a large/massive deployment of IPv6 that we can argue "the cat is out of the box". In any case, I believe this is a discussion to be had. There has been a lot of work around fragmentation and extension headers, with the more conservative folks still hoping that EHs are usable on the public Internet, and the other folks wishing EHs and fragmentation go away (and, well, actually making that happen by blocking them). So there seems to be a disconnect between what we expect the IPv6 Internet to be, and how it is being shaped (and is) in practice. IMHO, we should either accept what's becoming more and more of a fact (EHs and fragmentation being massively dropped on the public Internet; e.g. ), or try to do something to make them usable (after all, we're not planning for IPv7 anytime soon). All the above aside, the uniform format in RFC6465 cannot really work as specified. So it looks like, at the very least, a "please ignore section X of this document" is warranted... and/or a clear statement that we have abandoned the possibility of standardizing any new transport protocols (well, unless we encapsulate them over an existing one). 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 bjones@vt.edu Thu Feb 6 05:41:46 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F901A03CA for ; Thu, 6 Feb 2014 05:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.234 X-Spam-Level: X-Spam-Status: No, score=-3.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CrjIDfnGhLs for ; Thu, 6 Feb 2014 05:41:41 -0800 (PST) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by ietfa.amsl.com (Postfix) with ESMTP id 823DF1A00F2 for <6man@ietf.org>; Thu, 6 Feb 2014 05:41:41 -0800 (PST) Received: from mr5.cc.vt.edu (mr5.cc.vt.edu [198.82.141.27]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id s16Df997018905 for <6man@ietf.org>; Thu, 6 Feb 2014 08:41:10 -0500 Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by mr5.cc.vt.edu (8.14.4/8.14.4) with ESMTP id s16Df7WA029995 for <6man@ietf.org>; Thu, 6 Feb 2014 08:41:07 -0500 Received: by mail-qa0-f52.google.com with SMTP id j15so2714691qaq.39 for <6man@ietf.org>; Thu, 06 Feb 2014 05:41:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc:content-type; bh=XkRSJMfmXGcDh8nRFCd+Kk63Opmd8YHnzD8fXQGf4jU=; b=R+Za9RkII/rC5jZJi/iZq68jV5BMXODelU241CnPEAImz7DaqGCJ7RhONqqeEidmWL BszY+fuAdJC29+ituIBSrHBTOdrCU7AhJvrYMsKJGQI68uTzvSAqk6aAfiE3D5vLUfKr WmGas5ucDBDC1Yvjl5aUZ9JnJZKVxy0e3eZaJUqBUewHjLRW/wJ2Y48rX3d+skEVw0lf osVqEc4NVMtyg3yrG1D9aYULkbD+VmXe9cc/pLV3Q6EuplV5NBhUkdvnVH4m7wXPHatx ESemLtlNgFVAOC0tCbzrB2w2SV1NgtAZNv69HiTxFNcigDr6V2cz8Mu5Pc3kKbDouaCZ ECXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc:content-type; bh=XkRSJMfmXGcDh8nRFCd+Kk63Opmd8YHnzD8fXQGf4jU=; b=EMCx8CrnP3ZXi7ZmCei8VXoZXTZiBeJKweyW8i1MpLPMv8QQzehewlHE64004zZgs7 5MaqcLO9GPTOxEg4PMwUR3jYc+wvFNQCxZLTdu55QajEqJ9ocmYPGCtWl21AcFHklMkM upZURtHpqxZylVvpB0FdNrZtu1isVeyQJ9hCzdbvm6T2KkgHneAx+mOEkpdxp0gJIn5L Rbq8tRQOrWfc75m1VOfCF2o6l8Al0BuheHGySYH44HFs/LOu7V2vNE+046vWjDr3qM6z x53KOT9zKw6T3536Y1L0/EmRF7e080mw1u1uNTEr/n6IDBg2GLsTmMxDlsgt3hDWo8Mv Tdpg== X-Received: by 10.140.49.9 with SMTP id p9mr11580295qga.75.1391694067342; Thu, 06 Feb 2014 05:41:07 -0800 (PST) X-Gm-Message-State: ALoCoQnyUWR4TxzcJYT5FotKmpdvXWg0YJAjsZHEs9ag+FtG8fKvD9Nmc1yzniSkh0DTG3F8elVz+nrrCEBkPy4fCaVPMvjZrGzDS4fOhlwbEaG+CHxoLTAo7aLrEP9CFHz7HV8Fb56V X-Received: by 10.140.49.9 with SMTP id p9mr11580227qga.75.1391694066888; Thu, 06 Feb 2014 05:41:06 -0800 (PST) MIME-Version: 1.0 Sender: bjones@vt.edu Received: by 10.229.178.68 with HTTP; Thu, 6 Feb 2014 05:40:46 -0800 (PST) From: brianjusa Date: Thu, 6 Feb 2014 08:40:46 -0500 X-Google-Sender-Auth: DOtBK4oJGTFJ9cFfOy4Tlx2jMMA Message-ID: Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers To: Fernando Gont Content-Type: multipart/alternative; boundary=001a11351c9a7eac3604f1bd0648 X-Mailman-Approved-At: Thu, 06 Feb 2014 06:04:24 -0800 Cc: Thomas Narten , "C. M. Heard" , Tim Chown , "6man@ietf.org" <6man@ietf.org>, Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 13:41:47 -0000 --001a11351c9a7eac3604f1bd0648 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would hope that this group would not consider hindering IPv6 capability by designing for NAT compatibility=E2=80=A6 There is really no need for NAT= in the IPv6 world. -- Brian On Thu, Feb 6, 2014 at 7:44 AM, Fernando Gont wrote= : > Hi, Thomas, > > On 02/06/2014 09:21 AM, Thomas Narten wrote: > >> 1) If this problem remains un-addressed, then it's impossible to > >> differentiate between new upper-layer headers (e.g. a new transport > >> protocol) and new extension headers. Since such new extension headers > >> might be leveraged for malicious purposes, the end-result is that > >> middle-boxes are going to block *everything* (see RFC7045), which mean= s: > >> > >> + no new extension headers > >> + no new transport protocols > >> > >> ... so I think we really don't want to go there. > > > > But we are already there. Folk won't deploy anything other than > > TCP/UDP because NAT won't deal with it. That has already been reality > > and is the reason that other or new transport protocols appear to be > > virtually undeployable today. > > Well, IPv6 *might* give a fresh start in this respect -- there *might* > be IPv6 NAT.. but not necessarily. So.. while the end result might be > the same, it need not. > > I don't think we have widespread deployment of IPv6 NAT ("as we know it" > for IPv4), nor that we have such a large/massive deployment of IPv6 that > we can argue "the cat is out of the box". > > In any case, I believe this is a discussion to be had. There has been a > lot of work around fragmentation and extension headers, with the more > conservative folks still hoping that EHs are usable on the public > Internet, and the other folks wishing EHs and fragmentation go away > (and, well, actually making that happen by blocking them). > > So there seems to be a disconnect between what we expect the IPv6 > Internet to be, and how it is being shaped (and is) in practice. > > IMHO, we should either accept what's becoming more and more of a fact > (EHs and fragmentation being massively dropped on the public Internet; > e.g. > ), > or > try to do something to make them usable (after all, we're not planning > for IPv7 anytime soon). > > All the above aside, the uniform format in RFC6465 cannot really work as > specified. So it looks like, at the very least, a "please ignore section > X of this document" is warranted... and/or a clear statement that we > have abandoned the possibility of standardizing any new transport > protocols (well, unless we encapsulate them over an existing one). > > Thoughts? > > Thanks! > > Cheers, > -- > 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 > -------------------------------------------------------------------- > --001a11351c9a7eac3604f1bd0648 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I w= ould hope that this group would not consider hindering IPv6 capability by d= esigning for NAT compatibility=E2=80=A6 There is really no need for NAT in = the IPv6 world.

--
Brian

=
On Thu, Feb 6, 2014 at 7:44 AM, Fernando Gont <fgont@si6networks.com> wrote:
Hi, Thomas,

On 02/06/2014 09:21 AM, Thomas Narten wrote:
>> 1) If this problem remains un-addressed, then it's impossible = to
>> differentiate between new upper-layer headers (e.g. a new transpor= t
>> protocol) and new extension headers. Since such new extension head= ers
>> might be leveraged for malicious purposes, the end-result is that<= br> >> middle-boxes are going to block *everything* (see RFC7045), which = means:
>>
>> =C2=A0 + no new extension headers
>> =C2=A0 + no new transport protocols
>>
>> ... so I think we really don't want to go there.
>
> But we are already there. Folk won't deploy anything other than > TCP/UDP because NAT won't deal with it. That has already been real= ity
> and is the reason that other or new transport protocols appear to be > virtually undeployable today.

Well, IPv6 *might* give a fresh start in this respect -- there *might= *
be IPv6 NAT.. but not necessarily. So.. while the end result might be
the same, it need not.

I don't think we have widespread deployment of IPv6 NAT ("as we kn= ow it"
for IPv4), nor that we have such a large/massive deployment of IPv6 that we can argue "the cat is out of the box".

In any case, I believe this is a discussion to be had. There has been a
lot of work around fragmentation and extension headers, with the more
conservative folks still hoping that EHs are usable on the public
Internet, and the other folks wishing EHs and fragmentation go away
(and, well, actually making that happen by blocking them).

So there seems to be a disconnect between what we expect the IPv6
Internet to be, and how it is being shaped (and is) in practice.

IMHO, we should either accept what's becoming more and more of a fact (EHs and fragmentation being massively dropped on the public Internet;
e.g.
<http://iepg.org/2013-11-ietf88/fgont-iepg-ietf= 88-ipv6-frag-and-eh.pdf>), or
try to do something to make them usable (after all, we're not planning<= br> for IPv7 anytime soon).

All the above aside, the uniform format in RFC6465 cannot really work as specified. So it looks like, at the very least, a "please ignore secti= on
X of this document" is warranted... and/or a clear statement that we have abandoned the possibility of standardizing any new transport
protocols (well, unless we encapsulate them over an existing one).

Thoughts?

Thanks!

Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com<= br> 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
--------------------------------------------------------------------

--001a11351c9a7eac3604f1bd0648-- From brian.e.carpenter@gmail.com Thu Feb 6 11:46:38 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581171A0415 for ; Thu, 6 Feb 2014 11:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJhz9UYZnbXO for ; Thu, 6 Feb 2014 11:46:36 -0800 (PST) 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 C25361A03CA for <6man@ietf.org>; Thu, 6 Feb 2014 11:46:36 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id kq14so2125160pab.31 for <6man@ietf.org>; Thu, 06 Feb 2014 11:46:35 -0800 (PST) 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=5Y2QciVqcYgiyIi/LZZgUq0oKKUxAjRQjyJ/K0maYCM=; b=e+dnhj69zNVBd7jIyYC4DpUmgqAoaWqNub58gmgWdpYk4taHSgY8hrs9sIRR01U73c JMP8Pi1eThkv7gsnD2eHES+iF54WFcqHZUQXoW68Z2PBGgp/7xCEHO2kyVUkvrLJt/FT /RJCnMRx7DxFQtWmfaQDiv2klQ6De6HWyezzgMipxripDJi1SpFaOYCc806Q/KocAk6X dE8AGZaW6b3BQ2agcWdevEscDmyDHNlGFlDOPV5d2+Ms0nETTFj7286egk7SxMbrFwBL rQWEQ3Drcg0OSbVOhVI2zCcEHcTLyDRVpkyunGTdGj5OOwIXolB1kedDEJkyYdL4rAIV lh4A== X-Received: by 10.66.189.226 with SMTP id gl2mr2681874pac.65.1391715995616; Thu, 06 Feb 2014 11:46:35 -0800 (PST) Received: from [192.168.178.23] (33.195.69.111.dynamic.snap.net.nz. [111.69.195.33]) by mx.google.com with ESMTPSA id jk16sm6152295pbb.34.2014.02.06.11.46.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Feb 2014 11:46:34 -0800 (PST) Message-ID: <52F3E6A1.5010109@gmail.com> Date: Fri, 07 Feb 2014 08:46:41 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Narten Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <52F1B8CE.4070803@ericsson.com> <52F1BD1F.2080007@si6networks.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "C. M. Heard" , Fernando Gont , Tim Chown , "6man@ietf.org" <6man@ietf.org>, Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 19:46:38 -0000 On 07/02/2014 01:21, Thomas Narten wrote: > At Wed, 05 Feb 2014 01:25:03 -0300, Fernando Gont wrote: >> 1) If this problem remains un-addressed, then it's impossible to >> differentiate between new upper-layer headers (e.g. a new transport >> protocol) and new extension headers. Since such new extension headers >> might be leveraged for malicious purposes, the end-result is that >> middle-boxes are going to block *everything* (see RFC7045), which means: >> >> + no new extension headers >> + no new transport protocols >> >> ... so I think we really don't want to go there. > > But we are already there. Folk won't deploy anything other than > TCP/UDP because NAT won't deal with it. That has already been reality > and is the reason that other or new transport protocols appear to be > virtually undeployable today. > > Reality is that existing middleboxes tend to process what they > understand and have been explicitely coded to deal with. They just > punt on anything else because that is the easiest/safest thing to do. > > I see little that we can do to change that. I think we still have a chance with IPv6; of course the game is over for IPv4. That's why I worked on RFC 7045, and why I think it's worth trying to knock off this problem too. The current situation described in Fernando's draft is guaranteed to produce opaque middleboxes; we can at least make it possible to do better. Brian From randy@psg.com Thu Feb 6 16:23:57 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2208D1A0573 for ; Thu, 6 Feb 2014 16:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RANDOM_SURE=0.499, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GISJ_xghXCjE for ; Thu, 6 Feb 2014 16:23:56 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 0A38C1A0572 for <6man@ietf.org>; Thu, 6 Feb 2014 16:23:56 -0800 (PST) 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 1WBZEK-0001GA-Ap; Fri, 07 Feb 2014 00:23:40 +0000 Date: Fri, 07 Feb 2014 09:23:38 +0900 Message-ID: From: Randy Bush To: Fernando Gont Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers In-Reply-To: <52F383A0.7030002@si6networks.com> References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <52F1B8CE.4070803@ericsson.com> <52F1BD1F.2080007@si6networks.com> <52F383A0.7030002@si6networks.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: Thomas Narten , "C. M. Heard" , Tim Chown , "6man@ietf.org" <6man@ietf.org>, Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 00:23:57 -0000 >> But we are already there. Folk won't deploy anything other than >> TCP/UDP because NAT won't deal with it. That has already been reality >> and is the reason that other or new transport protocols appear to be >> virtually undeployable today. > > Well, IPv6 *might* give a fresh start in this respect -- there *might* > be IPv6 NAT.. but not necessarily. So.. while the end result might be > the same, it need not. and cash could fall from the sky randy From fgont@si6networks.com Thu Feb 6 18:54:05 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3240E1A05A3 for ; Thu, 6 Feb 2014 18:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RANDOM_SURE=0.499, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYGbO44aamQj for ; Thu, 6 Feb 2014 18:54:03 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 9891C1A05A2 for <6man@ietf.org>; Thu, 6 Feb 2014 18:54:03 -0800 (PST) Received: from [2001:5c0:1400:a::843] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WBbZc-000497-IF; Fri, 07 Feb 2014 03:53:48 +0100 Message-ID: <52F44A73.3000609@si6networks.com> Date: Thu, 06 Feb 2014 23:52:35 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Randy Bush Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <52F1B8CE.4070803@ericsson.com> <52F1BD1F.2080007@si6networks.com> <52F383A0.7030002@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , "C. M. Heard" , Tim Chown , "6man@ietf.org" <6man@ietf.org>, Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 02:54:05 -0000 Hi, Randy, On 02/06/2014 09:23 PM, Randy Bush wrote: >>> But we are already there. Folk won't deploy anything other than >>> TCP/UDP because NAT won't deal with it. That has already been reality >>> and is the reason that other or new transport protocols appear to be >>> virtually undeployable today. >> >> Well, IPv6 *might* give a fresh start in this respect -- there *might* >> be IPv6 NAT.. but not necessarily. So.. while the end result might be >> the same, it need not. > > and cash could fall from the sky You missed the rest of my response: I was simply arguing that NATs are not the reason for which anything other than TCP or UDP wouldn't fly over IPv6. The outcome might be the same... but for different reasons. However, what I believe is the high order bit of the discussion is to try bridge what seems to be a gap between standards making and operational reality. If what we're heading is towards "no new extensions nor transport protocols", let's spell that out. And if that's not the plan, let's see if there's anything that can be done fo that to be different. But to keep hearing that e.g. extensions are expected to work when I'm measuring over 40% of breakage, It seems to boil down to "you, heretic! don't filter these packets!" on one side and "shut up! you don't know how to run a network" on another. *That* doesn't seem to be the more sane approach to this issue. 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 Thu Feb 6 19:20:28 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDDA1A05A3 for ; Thu, 6 Feb 2014 19:20:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RANDOM_SURE=0.499, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXJSR_BA3irQ for ; Thu, 6 Feb 2014 19:20:27 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2221A059E for <6man@ietf.org>; Thu, 6 Feb 2014 19:20:27 -0800 (PST) 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 1WBbz6-0001xm-Qk; Fri, 07 Feb 2014 03:20:09 +0000 Date: Fri, 07 Feb 2014 12:20:15 +0900 Message-ID: From: Randy Bush To: Fernando Gont Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers In-Reply-To: <52F44A73.3000609@si6networks.com> References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <52F1B8CE.4070803@ericsson.com> <52F1BD1F.2080007@si6networks.com> <52F383A0.7030002@si6networks.com> <52F44A73.3000609@si6networks.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: Thomas Narten , "C. M. Heard" , Tim Chown , "6man@ietf.org" <6man@ietf.org>, Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 03:20:29 -0000 > But to keep hearing that e.g. extensions are expected to work when I'm > measuring over 40% of breakage, It seems to boil down to "you, > heretic! don't filter these packets!" on one side and "shut up! you > don't know how to run a network" on another. *That* doesn't seem to be > the more sane approach to this issue. not sane, but traditional. "you're idiots because you have not deployed ipv6." "you're arrogant fools because you have made it hard to deploy." randy From ietf@flo.fourcot.fr Fri Feb 7 04:53:03 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA571A03A6 for ; Fri, 7 Feb 2014 04:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3AZnRkk-Szm for ; Fri, 7 Feb 2014 04:53:01 -0800 (PST) Received: from olfflo.fourcot.fr (fourcot.fr [IPv6:2001:4b98:dc0:41:216:3eff:fe52:be3b]) by ietfa.amsl.com (Postfix) with ESMTP id 540141A0393 for ; Fri, 7 Feb 2014 04:53:00 -0800 (PST) Received: from reglisse.fourcot.fr (dud31.inf.tu-dresden.de [141.76.46.31]) (Authenticated sender: reglisse) by olfflo.fourcot.fr (Postfix) with ESMTPSA id 5DF562DF74; Fri, 7 Feb 2014 13:53:00 +0100 (CET) Received: from [IPv6:::1] (localhost [IPv6:::1]) by reglisse.fourcot.fr (Postfix) with ESMTPS id F2FE17F41C5; Fri, 7 Feb 2014 13:52:59 +0100 (CET) Message-ID: <52F4D72B.7020404@flo.fourcot.fr> Date: Fri, 07 Feb 2014 13:52:59 +0100 From: Florent Fourcot User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: brian.e.carpenter@gmail.com Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-01.txt] References: <52F2DC55.5070200@gmail.com> In-Reply-To: <52F2DC55.5070200@gmail.com> 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.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 12:53:03 -0000 Hello, Table 1 are Table 2 are exactly the same. Since the commentaries are not consistent, it is probably a typo error. Regards, -- Florent Fourcot. From fgont@si6networks.com Fri Feb 7 05:44:14 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7601E1A1EF8 for ; Fri, 7 Feb 2014 05:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RANDOM_SURE=0.499, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6Yb9H-alI6W for ; Fri, 7 Feb 2014 05:44:12 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4A11A00F5 for <6man@ietf.org>; Fri, 7 Feb 2014 05:44:11 -0800 (PST) Received: from [2001:5c0:1000:a::533] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WBlim-0002Xg-FS; Fri, 07 Feb 2014 14:43:56 +0100 Message-ID: <52F4DDC7.8070606@si6networks.com> Date: Fri, 07 Feb 2014 10:21:11 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ole Troan Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <52F1B8CE.4070803@ericsson.com> <52F1BD1F.2080007@si6networks.com> <52F383A0.7030002@si6networks.com> <52F44A73.3000609@si6networks.com> <86BA587E-A7F8-47B9-AC74-98D3DB9A7E46@employees.org> In-Reply-To: <86BA587E-A7F8-47B9-AC74-98D3DB9A7E46@employees.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , "6man@ietf.org" <6man@ietf.org>, "C. M. Heard" , Suresh Krishnan , Tim Chown X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 13:44:14 -0000 Hi, Ole, On 02/07/2014 06:05 AM, Ole Troan wrote: > >> But to keep hearing that e.g. extensions are expected to work >> when I'm measuring over 40% of breakage, It seems to boil down to >> "you, heretic! don't filter these packets!" on one side and "shut >> up! you don't know how to run a network" on another. *That* >> doesn't seem to be the more sane approach to this issue. > > I think we have to be careful throwing these numbers about without > qualifying them. > > aren't you in many cases detecting filtering in front of services, > where the operator has very good control of how their traffic > should look like? Probably, I guess -- I'm in the process of finding out where these packets are being filtered. But widespread filtering of stuff that is supposed to be "ignored if unsupported" eventually leads to "It's not usable, because if you try to, your packets get dropped". If, say, tomorrow you come up with this shiny cool new Dst Opt-based extension for clients, then, from starters, you would have to think of a back-up plan, because in more than 40% cases your packets would get dropped just because of that extension. -- that's where we are right now. > you are not saying if you, me and 8 of our other friends decided > to use a new L4 protocol we invented between ourselves, those > packets would in 40% of cases be filtered by the Internet core? I'm certainly not. But let's consider this: We want IPv6 to be extensible, so we have IPv6 extension headers. And we want middle-boxes to be able to find the upper layer header (or else the higher the chances our packets will be dropped on the floor). The options/scenarios are: 1) Pre-RFC6465: If I'm a middle-box and receive a packet, I have no way of telling whether it's a protocol that I'm supposed to allow (that just happens to have a unsupported EH), or an upper-layer protocol that I shouldn't be letting through. So my options: a) Drop those packets -- and now you have widespread deployment of devices at the edge that wouldn't allow new transport protocols or new EHs b) Allow everything -- which I doubt would be the case if e.g. any sort of firewalling is meant to be in place. 2) post-RFC6465/now: Firstly, I'd like to believe that RFC6465 has not been interpreted as "any other Next-Header values you don't explicitly support should follow the uniform format". Or else a new transport protocol would look (to any device trying to process the entire IPv6 header chain) like a malformed EH and get dropped. -- it might be a dumb interpretation.. but that's how many of us interpreted RFC6465 at one point or another. Secondly, we really need to provide a mechanism for middle-boxes to find the upper-layer header. Simple example: Let's say that I have a home firewall that is meant to just allow outgoing communication instances (for which extension headers are deemed as "fine"). Without a way to parsing new EHs (such as in the I-D we posted). Such firewall would simply drop new EHs, not because it wants, but rather because it has no way of telling what's an extension, and what's a protocol that it doesn't want to let through. In that case, we should completely forget about our ability to specify new (usable) EHs. Thoughts? Thanks, -- 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 Fri Feb 7 11:34:05 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE5C1A0274 for ; Fri, 7 Feb 2014 11:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IA4mpZqbut8 for ; Fri, 7 Feb 2014 11:34:03 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id C29BF1A00EA for ; Fri, 7 Feb 2014 11:34:03 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id ld10so3617090pab.38 for ; Fri, 07 Feb 2014 11:34:03 -0800 (PST) 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=hPTBDHNfo8sZB/ZFLxYwyM78Wjv5zCLXtSlgIEoiYIE=; b=V1nwhXA3D1sWpHgCRvHht8AdcPKvayyqFYrl4rnQ5fzhjlss99kAKHp3r6s4xM6HbK 78mCkBgdo527QdduSlAio0f5G9A8kRX5LlRvOW9RVNL0s+S+tIItlc9U0RFUHcX1kJCh 0Gp4FKfX5sd7UQ+sl/DmMzcbRX0esTZimaDA26JLrttr3eYWG9T2EbakOt/1OskZMOAC YE5wyzjP1xd4ywb1wSZDEZMoHYYCukGWqX05NRw/H6e0oKJ0iIeffwpwGqpG4mEiypSm SCFeQudSJHY04r2mm95jwrH2PcbIsC700wez58BWc1j5KOGawfDs6DDwFtjciLNPwMaP q4Yw== X-Received: by 10.68.134.130 with SMTP id pk2mr21482434pbb.167.1391801643678; Fri, 07 Feb 2014 11:34:03 -0800 (PST) Received: from [192.168.178.23] (208.199.69.111.dynamic.snap.net.nz. [111.69.199.208]) by mx.google.com with ESMTPSA id qf7sm40286733pac.14.2014.02.07.11.34.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Feb 2014 11:34:02 -0800 (PST) Message-ID: <52F53535.9080607@gmail.com> Date: Sat, 08 Feb 2014 08:34:13 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Florent Fourcot Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-01.txt] References: <52F2DC55.5070200@gmail.com> <52F4D72B.7020404@flo.fourcot.fr> In-Reply-To: <52F4D72B.7020404@flo.fourcot.fr> 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.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 19:34:05 -0000 On 08/02/2014 01:52, Florent Fourcot wrote: > Hello, > > Table 1 are Table 2 are exactly the same. Since the commentaries are not > consistent, it is probably a typo error. Fernando should really answer this, because he ran the tests, but I don't see the problem. The results happen to be identical for <64 or >64, and the commentaries say that too. We could save some space by presenting only one table, I suppose. Brian From karsten_thomann@linfre.de Fri Feb 7 12:51:39 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04551AD603 for ; Fri, 7 Feb 2014 12:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_G3ZCWkf98V for ; Fri, 7 Feb 2014 12:51:36 -0800 (PST) Received: from linfre.de (linfre.de [83.151.26.85]) by ietfa.amsl.com (Postfix) with ESMTP id DB5811A0459 for ; Fri, 7 Feb 2014 12:51:35 -0800 (PST) Received: from linne.localnet (194.64.241.52) by linfreserv.linfre (Axigen) with (AES256-SHA encrypted) ESMTPSA id 3135A4; Fri, 7 Feb 2014 21:51:20 +0100 From: Karsten Thomann To: ipv6@ietf.org Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers Date: Fri, 07 Feb 2014 21:51:24 +0100 Message-ID: <9041847.E8qsebI4ky@linne> User-Agent: KMail/4.10.4 (Windows/6.1; KDE/4.10.4; i686; ; ) In-Reply-To: <52F4DDC7.8070606@si6networks.com> References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <86BA587E-A7F8-47B9-AC74-98D3DB9A7E46@employees.org> <52F4DDC7.8070606@si6networks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart4786983.evWmSXvX4y" Content-Transfer-Encoding: 7Bit X-AXIGEN-DK-Result: No records DomainKey-Status: no signature X-AxigenSpam-Level: 5 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 20:51:39 -0000 This is a multi-part message in MIME format. --nextPart4786983.evWmSXvX4y Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Am Freitag, 7. Februar 2014, 10:21:11 schrieb Fernando Gont: > Hi, Ole, > > On 02/07/2014 06:05 AM, Ole Troan wrote: > >> But to keep hearing that e.g. extensions are expected to work > >> when I'm measuring over 40% of breakage, It seems to boil down to > >> "you, heretic! don't filter these packets!" on one side and "shut > >> up! you don't know how to run a network" on another. *That* > >> doesn't seem to be the more sane approach to this issue. > > > > I think we have to be careful throwing these numbers about without > > qualifying them. > > > > aren't you in many cases detecting filtering in front of services, > > where the operator has very good control of how their traffic > > should look like? > > Probably, I guess -- I'm in the process of finding out where these > packets are being filtered. > > But widespread filtering of stuff that is supposed to be "ignored if > unsupported" eventually leads to "It's not usable, because if you try > to, your packets get dropped". > > If, say, tomorrow you come up with this shiny cool new Dst Opt-based > extension for clients, then, from starters, you would have to think of > a back-up plan, because in more than 40% cases your packets would get > dropped just because of that extension. -- that's where we are right now. > > > you are not saying if you, me and 8 of our other friends decided > > to use a new L4 protocol we invented between ourselves, those > > packets would in 40% of cases be filtered by the Internet core? > > I'm certainly not. > > But let's consider this: > > We want IPv6 to be extensible, so we have IPv6 extension headers. And > we want middle-boxes to be able to find the upper layer header (or > else the higher the chances our packets will be dropped on the floor). > The options/scenarios are: > > 1) Pre-RFC6465: If I'm a middle-box and receive a packet, I have no > way of telling whether it's a protocol that I'm supposed to allow > (that just happens to have a unsupported EH), or an upper-layer > protocol that I shouldn't be letting through. So my options: > a) Drop those packets -- and now you have widespread deployment of > devices at the edge that wouldn't allow new transport > protocols or new EHs > > b) Allow everything -- which I doubt would be the case if e.g. any > sort of firewalling is meant to be in place. > > 2) post-RFC6465/now: > Firstly, I'd like to believe that RFC6465 has not been interpreted as > "any other Next-Header values you don't explicitly support should > follow the uniform format". Or else a new transport protocol would > look (to any device trying to process the entire IPv6 header chain) > like a malformed EH and get dropped. -- it might be a dumb > interpretation.. but that's how many of us interpreted RFC6465 at one > point or another. > > Secondly, we really need to provide a mechanism for middle-boxes to > find the upper-layer header. Simple example: Let's say that I have a > home firewall that is meant to just allow outgoing communication > instances (for which extension headers are deemed as "fine"). Without > a way to parsing new EHs (such as in the I-D we posted). Such firewall > would simply drop new EHs, not because it wants, but rather because it > has no way of telling what's an extension, and what's a protocol that > it doesn't want to let through. In that case, we should completely > forget about our ability to specify new (usable) EHs. > > > Thoughts? > > Thanks, Hi, I think the "simple" solution is to provide middle boxes an offset to the upper layer header, if the EH is unknown to the box, it can still identify the upperlayer. With that offset every middlebox can identify the used transport protocol without knowledge of any future EH. I know that it is not that easy and has it's own pros and cons, but I provide it as an idea to solve the problem. Regards Karsten --nextPart4786983.evWmSXvX4y Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

Am Freitag, 7. Februar 2014, 10:21:11 schrieb Fernando Gont:

> Hi, Ole,

>

> On 02/07/2014 06:05 AM, Ole Troan wrote:

> >> But to keep hearing that e.g. extensions are expected to work

> >> when I'm measuring over 40% of breakage, It seems to boil down to

> >> "you, heretic! don't filter these packets!" on one side and "shut

> >> up! you don't know how to run a network" on another. *That*

> >> doesn't seem to be the more sane approach to this issue.

> >

> > I think we have to be careful throwing these numbers about without

> > qualifying them.

> >

> > aren't you in many cases detecting filtering in front of services,

> > where the operator has very good control of how their traffic

> > should look like?

>

> Probably, I guess -- I'm in the process of finding out where these

> packets are being filtered.

>

> But widespread filtering of stuff that is supposed to be "ignored if

> unsupported" eventually leads to "It's not usable, because if you try

> to, your packets get dropped".

>

> If, say, tomorrow you come up with this shiny cool new Dst Opt-based

> extension for clients, then, from starters, you would have to think of

> a back-up plan, because in more than 40% cases your packets would get

> dropped just because of that extension. -- that's where we are right now.

>

> > you are not saying if you, me and 8 of our other friends decided

> > to use a new L4 protocol we invented between ourselves, those

> > packets would in 40% of cases be filtered by the Internet core?

>

> I'm certainly not.

>

> But let's consider this:

>

> We want IPv6 to be extensible, so we have IPv6 extension headers. And

> we want middle-boxes to be able to find the upper layer header (or

> else the higher the chances our packets will be dropped on the floor).

> The options/scenarios are:

>

> 1) Pre-RFC6465: If I'm a middle-box and receive a packet, I have no

> way of telling whether it's a protocol that I'm supposed to allow

> (that just happens to have a unsupported EH), or an upper-layer

> protocol that I shouldn't be letting through. So my options:

> a) Drop those packets -- and now you have widespread deployment of

> devices at the edge that wouldn't allow new transport

> protocols or new EHs

>

> b) Allow everything -- which I doubt would be the case if e.g. any

> sort of firewalling is meant to be in place.

>

> 2) post-RFC6465/now:

> Firstly, I'd like to believe that RFC6465 has not been interpreted as

> "any other Next-Header values you don't explicitly support should

> follow the uniform format". Or else a new transport protocol would

> look (to any device trying to process the entire IPv6 header chain)

> like a malformed EH and get dropped. -- it might be a dumb

> interpretation.. but that's how many of us interpreted RFC6465 at one

> point or another.

>

> Secondly, we really need to provide a mechanism for middle-boxes to

> find the upper-layer header. Simple example: Let's say that I have a

> home firewall that is meant to just allow outgoing communication

> instances (for which extension headers are deemed as "fine"). Without

> a way to parsing new EHs (such as in the I-D we posted). Such firewall

> would simply drop new EHs, not because it wants, but rather because it

> has no way of telling what's an extension, and what's a protocol that

> it doesn't want to let through. In that case, we should completely

> forget about our ability to specify new (usable) EHs.

>

>

> Thoughts?

>

> Thanks,

 

Hi,

 

I think the "simple" solution is to provide middle boxes an offset to the upper layer header, if the EH is unknown to the box, it can still identify the upperlayer.

 

With that offset every middlebox can identify the used transport protocol without knowledge of any future EH.

 

I know that it is not that easy and has it's own pros and cons, but I provide it as an idea to solve the problem.

 

Regards

Karsten

--nextPart4786983.evWmSXvX4y-- From hagen@jauu.net Fri Feb 7 14:19:12 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED711A0449 for ; Fri, 7 Feb 2014 14:19:12 -0800 (PST) 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=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYZDk3CDolrE for ; Fri, 7 Feb 2014 14:19:09 -0800 (PST) Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2001:4d88:1ffa:82:880:aa0:9009:64ae]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF671A021E for <6man@ietf.org>; Fri, 7 Feb 2014 14:19:09 -0800 (PST) Received: from pfeifer by Chamillionaire.breakpoint.cc with local (Exim 4.80) (envelope-from ) id 1WBtjw-0008OO-Dk; Fri, 07 Feb 2014 23:17:40 +0100 Date: Fri, 7 Feb 2014 23:23:39 +0100 From: Hagen Paul Pfeifer To: Thomas Narten Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers Message-ID: <20140207222339.GA28019@localhost.localdomain> References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <52F1B8CE.4070803@ericsson.com> <52F1BD1F.2080007@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "C. M. Heard" , Fernando Gont , Tim Chown , "6man@ietf.org" <6man@ietf.org>, Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 22:19:12 -0000 * Thomas Narten | 2014-02-06 07:21:49 [-0500]: >But we are already there. Folk won't deploy anything other than >TCP/UDP because NAT won't deal with it. That has already been reality >and is the reason that other or new transport protocols appear to be >virtually undeployable today. Maybe actual in parts of the Internet. We deploy larger networks with our router silicon and we _use_ IPv6 extension header to transport signaling information. Period. Our need is not on the protocol side - UDP is fine for all - we need additional extension header (think about roaming information). And we _have_ actual problems with the current situation! This is why I wrote the I-D back in 2011[1]. I remember a time where ECN did not work properly and where dropped occasionally by broken middleboxes. LKML started to enabled ECN and things improved over time. We should not stop solutions here because administrators/vendors infringe protocol best practices. We should focus on an proper protocol design which enables possibilities. Hagen [1] http://tools.ietf.org/html/draft-pfeifer-6man-exthdr-res-01 From brian.e.carpenter@gmail.com Fri Feb 7 14:53:28 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EC11AD687 for ; Fri, 7 Feb 2014 14:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kB_gNQ83PQ5 for ; Fri, 7 Feb 2014 14:53:26 -0800 (PST) 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 B0AC81AD669 for ; Fri, 7 Feb 2014 14:53:26 -0800 (PST) Received: by mail-pd0-f181.google.com with SMTP id y10so3717589pdj.12 for ; Fri, 07 Feb 2014 14:53:26 -0800 (PST) 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=Mo+7uJ3FXA/753G1ZcFsUcJtlmZpJJqx904/s1uquoA=; b=UARKdtA2n11Xp29QFv/iuC0I6gWB+J4ch8GPVwQD9vgegL2cQSn1MDVo+Xei1m+4EB EnihjzW24DxP2e+msJBsmkyllJOkAIbQV7NnbUSrZZPG/fW+Qiy1B+n7dCTUKBIe5EQa BZ5gh9fm+bc5QBUOth1Aeu3oHEyNNPTX3vw6SQKwiHURRRMvQUBEtDUPUiL+F2Qi48ig UatEMFhXvAl7HqhpQzaXM4IdU8NoEAXs4uK9PA/qo9OnNXLas+m5VbBzCDzDqbeZ2u00 wYTgDucSdHt+QCdUpBfV97GHPoBB3Xv/zlPQ6dYGX87REBIFR6WH2cr4LBggZQLyJ2Fy ujTQ== X-Received: by 10.68.197.234 with SMTP id ix10mr22523578pbc.80.1391813606590; Fri, 07 Feb 2014 14:53:26 -0800 (PST) Received: from [192.168.178.23] (208.199.69.111.dynamic.snap.net.nz. [111.69.199.208]) by mx.google.com with ESMTPSA id g6sm43563028pat.2.2014.02.07.14.53.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Feb 2014 14:53:25 -0800 (PST) Message-ID: <52F563F1.5080201@gmail.com> Date: Sat, 08 Feb 2014 11:53:37 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Karsten Thomann Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <86BA587E-A7F8-47B9-AC74-98D3DB9A7E46@employees.org> <52F4DDC7.8070606@si6networks.com> <9041847.E8qsebI4ky@linne> In-Reply-To: <9041847.E8qsebI4ky@linne> 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.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 22:53:28 -0000 On 08/02/2014 09:51, Karsten Thomann wrote: ... > Hi, > > I think the "simple" solution is to provide middle boxes an offset to the upper layer header, if the > EH is unknown to the box, it can still identify the upperlayer. This was suggested a while back but there was no enthusiasm for it. http://tools.ietf.org/html/draft-zhang-6man-offset-option-01 Brian > > With that offset every middlebox can identify the used transport protocol without knowledge of > any future EH. > > I know that it is not that easy and has it's own pros and cons, but I provide it as an idea to solve > the problem. > > Regards > Karsten > > > > ------------------------------------------------------------------------ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From markzzzsmith@yahoo.com.au Fri Feb 7 16:06:32 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE51E1AD7C1 for ; Fri, 7 Feb 2014 16:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.347 X-Spam-Level: * X-Spam-Status: No, score=1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RANDOM_SURE=0.499, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgKcOV8NpsNa for ; Fri, 7 Feb 2014 16:06:30 -0800 (PST) Received: from nm9-vm0.bullet.mail.bf1.yahoo.com (nm9-vm0.bullet.mail.bf1.yahoo.com [98.139.213.154]) by ietfa.amsl.com (Postfix) with ESMTP id AAB9C1AD79D for <6man@ietf.org>; Fri, 7 Feb 2014 16:06:30 -0800 (PST) Received: from [66.196.81.170] by nm9.bullet.mail.bf1.yahoo.com with NNFMP; 08 Feb 2014 00:06:30 -0000 Received: from [98.139.212.248] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 08 Feb 2014 00:06:30 -0000 Received: from [127.0.0.1] by omp1057.mail.bf1.yahoo.com with NNFMP; 08 Feb 2014 00:06:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 404329.87187.bm@omp1057.mail.bf1.yahoo.com Received: (qmail 87982 invoked by uid 60001); 8 Feb 2014 00:06:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1391817990; bh=3Y80cbn6RHuA9k8Gx2kue6LyyJKWoKe+2R4rAJHNgFM=; 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=s2FiMGfawj3Ta7btaUbyN9WbJiFVzMPiNHnOGH5CtCZie6krZlcZBlNJXhe9O0pTX0vlhwAUErEASh0kQBfALJtF4zKAw2CZR0/YJanI6ur7FeJs5qgegY49HJ0yOFCZG5zSdntpVYOINyLn0Zg4OpnEMjXDdtwPo2V2n03pLXk= 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=0Vjx222bQ3P9Rn4V+XH97THWyLmjKkWRPte7p+00MU4jx3nCRgY7r4BAstcRlWUGVwq4cxlCVJ/ZVMw5uBHtuHa6xHJ7EH2u1LTuZh/Mx2uAFK7BFnEHAfJxzAPqPk42HHMNGjNv7a5w+XoV4rBVZ1o7yIQcCwbnEIHvS7cEpNI=; X-YMail-OSG: wCWeEAIVM1mQzj4JxSF1DzSRaF.l0MBchQgcuerj4FfT51D ud6gHdXApFfKtHjyAGrGH3N_vTQUk2fKr42XvVTtpb4gmNjXq_tly.ddTleb NZVNauOj9umR4a4Z.dTJb4F7Rmn__BnkC.d5PYi8wZpUYW0h3jf8Y_p.mUTm chQ3byll5oDJVUjysJo8_Rjq5TD6tq3ctl2dBdP8AnkyYCLspdSNqtdUL66J rf48ohd47DGkOgygWzGl0rb2oFseRcXgMSkilhNfSS27WLPTTgvUN4oz97B7 xPT9OyxX0sgvh9NrTS7TuSb_Z9veQPWMftsgHtOBfBkCHli07zyzsOG1s0CR AkAJagX32fjBWTsGiOY6FEWCFdzWzVsTOyFS3TffgzzHccEkDoytmvXePtae fZ26croTJbH1rjoMgzqqxGUW5_edzCunYHW6sDn_keHE00FO_uVqTpmlewVJ PSefLHBMfeyGHm59nom7ubmY45U3o25o90KM_HStJE.hDCp7EI5YgwwWwjRp nuPEb_RPN9MToy8D_5Si6EKDdbHJsCbnbL07v6gkgjCONMWFOqAcrI9UBEWR UqpwTSlEoGa.zeyDBunUS9Ro7SorZlE9SXFvbdbQh29NK8weB_l7arV5hx6D yaGtJpesfRkCbkLb.T0x1ip04qxxfETXU3lBiT4YBjmGPwXJKYw4mrXwNtgJ g1AYcJOQ.eUsWbpmsgtAXF1ffCWHtdSmcK7z1x3lRTQ-- Received: from [150.101.221.237] by web162204.mail.bf1.yahoo.com via HTTP; Fri, 07 Feb 2014 16:06:29 PST X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20.Cj4gVG86IE9sZSBUcm9hbiA8b3Ryb2FuQGVtcGxveWVlcy5vcmc.Cj4gQ2M6IFRob21hcyBOYXJ0ZW4gPG5hcnRlbkB1cy5pYm0uY29tPjsgIjZtYW5AaWV0Zi5vcmciIDw2bWFuQGlldGYub3JnPjsgQy4gTS4gSGVhcmQgPGhlYXJkQHBvYm94LmNvbT47IFN1cmVzaCBLcmlzaG5hbiA8c3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbT47IFRpbSBDaG93biA8dGpjQGVjcy4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.175.632 References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <52F1B8CE.4070803@ericsson.com> <52F1BD1F.2080007@si6networks.com> <52F383A0.7030002@si6networks.com> <52F44A73.3000609@si6networks.com> <86BA587E-A7F8-47B9-AC74-98D3DB9A7E46@employees.org> <52F4DDC7.8070606@si6networks.com> Message-ID: <1391817989.71306.YahooMailNeo@web162204.mail.bf1.yahoo.com> Date: Fri, 7 Feb 2014 16:06:29 -0800 (PST) From: Mark ZZZ Smith Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers To: Fernando Gont , Ole Troan In-Reply-To: <52F4DDC7.8070606@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Thomas Narten , "C. M. Heard" , Tim Chown , "6man@ietf.org" <6man@ietf.org>, Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 08 Feb 2014 00:06:32 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Fernando Gont =0A> To: Ole Troan =0A> Cc: Thomas Narte= n ; "6man@ietf.org" <6man@ietf.org>; C. M. Heard ; Suresh Krishnan ; Tim Chown =0A> Sent: Saturday, 8 February 2014 12:21 AM=0A> Subject: = Re: A problem with RFC 6465's Uniform Format for Extension Headers=0A> =0A>= Hi, Ole,=0A> =0A> On 02/07/2014 06:05 AM, Ole Troan wrote:=0A>> =0A>>> Bu= t to keep hearing that e.g. extensions are expected to work=0A>>> when I'm= measuring over 40% of breakage, It seems to boil down to=0A>>> "you, here= tic! don't filter these packets!" on one side =0A> and "shut=0A>>> up! you= don't know how to run a network" on another. *That*=0A>>> doesn't seem to= be the more sane approach to this issue.=0A>> =0A>> I think we have to be= careful throwing these numbers about without =0A>> qualifying them.=0A>> = =0A>> aren't you in many cases detecting filtering in front of services, = =0A>> where the operator has very good control of how their traffic=0A>> = should look like?=0A> =0A> Probably, I guess -- I'm in the process of findi= ng out where these=0A> packets are being filtered.=0A> =0A> But widespread = filtering of stuff that is supposed to be "ignored if=0A> unsupported" even= tually leads to "It's not usable, because if you =0A> try=0A> to, your pack= ets get dropped".=0A> =0A> If, say, tomorrow you come up with this shiny co= ol new Dst Opt-based=0A> extension for clients, then, from starters, you wo= uld have to think of=0A> a back-up plan, because in more than 40% cases you= r packets would get=0A> dropped just because of that extension. -- that's w= here we are right now.=0A>=A0=0A=0AEnd-to-end crypto might the backup plan.= I think it might be worth remembering that as per the IETF88 Plenary, end-= to-end encryption is the general direction, and that middle boxes less effe= ctive/in-effective because of it. So putting a lot of time and effort into = facilitating them might be wasted effort.=0A=0AI also think multipathing, t= o take advantage of smartphone/tablet's multi-homing to the network will al= so mean middle boxes become less effective/in-effective. IOS 7 is already u= sing MPTCP for Siri for example+.=0A=0A=0A=0ARegards,=0AMark.=0A=0A= =0A+ -=A0http://perso.uclouvain.be/olivier.bonaventure/blog/html/2013/09/18= /mptcp.html From ietf@rozanak.com Sat Feb 8 12:01:16 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71941A060C; Sat, 8 Feb 2014 12:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYiH8O_4ctmO; Sat, 8 Feb 2014 12:01:14 -0800 (PST) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) by ietfa.amsl.com (Postfix) with ESMTP id 588711A0619; Sat, 8 Feb 2014 12:01:08 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 58B4723E2D5A; Sat, 8 Feb 2014 20:01:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcLFNRkFDyx9; Sat, 8 Feb 2014 21:01:06 +0100 (CET) Received: from kopoli (g229053098.adsl.alicedsl.de [92.229.53.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 7366E23E2D59; Sat, 8 Feb 2014 21:01:06 +0100 (CET) From: "Hosnieh Rafiee" To: , Subject: CGA Attack - SSAS - Local security deployments Date: Sat, 8 Feb 2014 21:01:00 +0100 Message-ID: <001a01cf2508$7e3e4550$7abacff0$@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: Ac8lCHrgzGLjMFuFQgehqo0uG/cREA== Content-Language: en-us X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 20:01:17 -0000 I uploaded a new version of a possible attack on CGA. This is an = informational document that complements SSAS document along with another = document http://tools.ietf.org/html/draft-rafiee-6man-local-security = that focuses on deployments. I appreciate your comments on SSAS ( = http://tools.ietf.org/html/draft-rafiee-6man-ssas) , local security and = CGA attacks You can expect new version of SSAS in a couple of days. I am looking = forward to finding more people who are interested to work with me on = this document and make it ready for a BoF discussion in the next IETF. = This is because the result of 6man WG was not based on the supporters of = SSAS document. You can directly send me your comments or to the mailing list. -----------smile---------- Hosnieh > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Saturday, February 08, 2014 8:34 PM > To: Hosnieh Rafiee; Christoph Meinel; Christoph Meinel; Hosnieh > Subject: New Version Notification for = draft-rafiee-6man-cga-attack-01.txt >=20 >=20 > A new version of I-D, draft-rafiee-6man-cga-attack-01.txt > has been successfully submitted by Hosnieh Rafiee and posted to the = IETF > repository. >=20 > Name: draft-rafiee-6man-cga-attack > Revision: 01 > Title: Possible Attack on Cryptographically Generated Addresses > (CGA) > Document date: 2014-02-08 > Group: Individual Submission > Pages: 7 > URL: = http://www.ietf.org/internet-drafts/draft-rafiee-6man-cga-attack- > 01.txt > Status: = https://datatracker.ietf.org/doc/draft-rafiee-6man-cga-attack/ > Htmlized: = http://tools.ietf.org/html/draft-rafiee-6man-cga-attack-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-rafiee-6man-cga-attack-01 >=20 > Abstract: > This document describes the new vulnerability with the use of > Cryptographically Generated Addresses. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat From heard@pobox.com Sun Feb 9 11:35:41 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E461A0545 for ; Sun, 9 Feb 2014 11:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZUfcjl8FSsC for ; Sun, 9 Feb 2014 11:35:39 -0800 (PST) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6801A0443 for <6man@ietf.org>; Sun, 9 Feb 2014 11:35:39 -0800 (PST) Received: (qmail 16082 invoked from network); 9 Feb 2014 11:35:37 -0800 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Feb 2014 11:35:37 -0800 Date: Sun, 9 Feb 2014 11:35:37 -0800 (PST) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: 6MAN <6man@ietf.org> Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers In-Reply-To: <52F13D1D.9050800@gont.com.ar> Message-ID: References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <52F13D1D.9050800@gont.com.ar> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 19:35:41 -0000 On Tue, 4 Feb 2014, Fernando Gont wrote: > On 02/04/2014 11:20 AM, Jen Linkova wrote: > > Somehow that proposed Universal Extension Header looks exactly like an > > Options Extension Header to me. > > Am I missing something? I'm trying to use my imagination but couldn't > > see any possible scenario when UEH would work and Options header would > > not. In an offline discussion with Fernando before his draft was submitted I made the following comments: | This seems technically sound and is probably what RFC 6564 should | have said in the first place. However, playing devil's advocate, | let me ask if there is a reason why the Destination Options header | would not serve the same purpose as the universal extension header | [...], so long as that header is allowed to appear multiple times at | any position in between the Hop-By-Hop options header (if present) | and the Fragment Header or the upper layer header. In the absence of a strong argument to the contrary, it seems to me that the existing Destination Options header can be used to do exactly the same thing as the proposed UEH. In other words, I agree with Jen's comments. Fernando went on to write: > Not sure what you mean. > > But please let me provide an example: > > Let's say that, tomorrow, the IETF standardizes the GTP (Google > Transport Protocol :-)), and it is assigned the Next Header value 0xFF > (I'm assuming this one is not currently assigned, bbut I'm not checking > the IANA registry right now). > > Say a middle-box receives a packet that simply encapsulates GTP in IPv6, > and that middlebox does not yet support GTP. If the middle-box tries to > interpret the GTP header as in RFC6465, it will certainly fail. > > The reason? -- RFC 6465 implicitly assumes that every new Next Header > will employ the RFC6465 format. This may be sensible for new *extension > headers*, but certainly not for new transport protocols. > > And since transport protocols and extension headers share the same > namespace (see RFC7045), this is a problem. All this is true. The implication is that the middlebox must stop parsing the header chain when it encounters an unknown Next Header. In more detail, I see the three cases: 1.) The middlebox encounters an ESP Next Header, signalling that an encrypted payload follows. In that case it stops parsing the header chain and applies its policy for encrypted payloads. 2.) The middlebox encounters a Next Header corresponding to a known transport protocol. In that case it may perform filtering actions specific to that transport protocol (and of course may continue parsing into the transport header in order to do so). 3.) The middlebox encounters an unknown Next Header value. In that case it stops parsing the header chain and applies its policy for packets with unknown Next Header values. In order to comply with RFC 7045, it MUST be possible to configure the policy to allow such packets, but the default MAY be to drop them. A high-quality implementation would allow the policy to be configured individually for each unknown Next Header value. I agree that there are use cases where it is important for a middlebox to clearly distinguish between an unknown extension header and an unknown transport protocol. One is RA Guard: see https://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard-implementation/ > What we did in our I-D is specify a new Extension Header, that is > assigned a Next-Header value. Let us assume that our proposal moves > forward, and the UEH is assigned the next header value 0xfe. > > If a middle-box supports UEH but does not support our (fictitious) GTP > protocol above, then, if a GTP packet encapsulated in IPv6 is received, > GTP will be identified as an "upper-layer protocol", rather than as UEH > (since the Next Header value will be 0xff, rather than UEH's 0xfe). > > Clearly, another way to go is to reserve part of the IANA's Next Header > namespace for RFC6465, and leave the rest for transport protocols -- as > suggested by Hagen. > > What's clear is that the only way in which RFC6465 can possibly work is > if the middle-box has some a-priori knowledge that what is being > encapsulated follows RFC6465 -- whether as a result of a reserved range > (as originally proposed by Hagen) or by specifying a single UEH, and > then encoding all possible future "extension headers" as subtypes of UEH. A third possibility would be to go a step further than RFC 6564 and ban new extension headers outright, insisting that a Destination Option be used instead. RFC 6564 already says that a new extension header may be defined only as a last resort, requiring proof that a Destination Option will not work. Can anyone offer up a scenario where a Destination Option will not work? Mike Heard From brian.e.carpenter@gmail.com Sun Feb 9 14:44:09 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CCC1A0618 for ; Sun, 9 Feb 2014 14:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCYgKPYkZDvE for ; Sun, 9 Feb 2014 14:44:06 -0800 (PST) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B2F031A0506 for <6man@ietf.org>; Sun, 9 Feb 2014 14:44:06 -0800 (PST) Received: by mail-pb0-f45.google.com with SMTP id un15so5467339pbc.32 for <6man@ietf.org>; Sun, 09 Feb 2014 14:44:07 -0800 (PST) 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=ky+IAmSUt+gZgtOznRcH5eYQiAanSIo+nkQeoWxM12E=; b=f62A/G7qFwqEJzZRlA7Icm1SLnhsSTYy6VLLKOf7uX3JEHaV0Z/z9S5I6I23P8cn50 3HTMno5dZf+QCDLd2lCduyJSKoR08rB4UB+Mp+zYWT2HNdpFuUGvvc3MJsr9h90CdSvN jPNpj1ZRPraxzx3z2MEyP+ombrXUZMU5YtUytdHkIPDGtzCt9W6zsHNnoi4Y4MobusF5 YM4qud/PPnTsK9GlNkIqe/kPu4fgdXZmhMg+YUZ3QnBigNxCCbUZb7lwpUnZlydXshrc 9NWmCmjwNhWnUJqSPWyrW/QhHT3TL23ljei922dhMNXqLwtXh5OYdPvtrRNBdNQGdg5i IZfg== X-Received: by 10.68.176.65 with SMTP id cg1mr5476585pbc.145.1391985846949; Sun, 09 Feb 2014 14:44:06 -0800 (PST) Received: from [192.168.178.23] (82.197.69.111.dynamic.snap.net.nz. [111.69.197.82]) by mx.google.com with ESMTPSA id q7sm35749629pbc.20.2014.02.09.14.44.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Feb 2014 14:44:06 -0800 (PST) Message-ID: <52F804B3.5040803@gmail.com> Date: Mon, 10 Feb 2014 11:44:03 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "C. M. Heard" Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <52F13D1D.9050800@gont.com.ar> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , 6MAN <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 22:44:09 -0000 On 10/02/2014 08:35, C. M. Heard wrote: ... > In the absence of a strong argument to the contrary, it seems to me > that the existing Destination Options header can be used to do > exactly the same thing as the proposed UEH. In other words, I agree > with Jen's comments. I think we should carry out a thought experiment: consider each of the existing extension headers, listed in RFC 7045 and at http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header and see which of them could or could not be encoded as destination options. For some of them the answer is obvious, of course. But the others would give us an idea whether the 'option' option has enough flexibility. Brian From jouni.nospam@gmail.com Mon Feb 10 01:23:41 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF6C1A07C0 for ; Mon, 10 Feb 2014 01:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBNYlI4W9lno for ; Mon, 10 Feb 2014 01:23:39 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id 84A981A06A9 for ; Mon, 10 Feb 2014 01:23:39 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id u14so4635768lbd.9 for ; Mon, 10 Feb 2014 01:23:38 -0800 (PST) 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; bh=WXKftyRpaVE6iAs0ZjZWIQnDGeogiXvkTguBp4uqIUQ=; b=jA9BksbmvNIK7mXNVw12OlYcTU8leoVuVSd34WFdvNkFHgNiNyqSfLLyz06v2hHItx nMMP7THg0lwpGHCs/TfLDdh6WS2YX+w06qVthqqAf6NKfey59HMQsBXc56K353n2LiPC qlGwsqfvNtLyuQnxhjMQygNv5wdYjD1VOl5CNi8Js3+vjWOZcu7g3I82Cl5/ER+O75HC 7zSnWHhOSiHG+2e6tMRwXFpT8pL8YZM7DCNeiIUEI9RY9ASmmlyI/abT0XU7zTuoAbYg 8njh5NiWjfNrsthPpFFOlSu0ULvdPiWCar/exlo7JCEaGqt9cLLoK8bmxRXo1FdnPY/s G4CQ== X-Received: by 10.152.42.196 with SMTP id q4mr468742lal.52.1392024218817; Mon, 10 Feb 2014 01:23:38 -0800 (PST) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id gi5sm15130124lbc.4.2014.02.10.01.23.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 01:23:38 -0800 (PST) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Comments on draft-ietf-6man-multicast-addr-arch-update-02 Message-Id: Date: Mon, 10 Feb 2014 11:23:37 +0200 To: IPv6 IPv6 List , draft-ietf-6man-multicast-addr-arch-update@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 09:23:41 -0000 Sorry being a bit late but I had a read of this document. ** Some nits: s/[ADDRARCH]/[RFC4291] ** While I agree this document is needed there is a general procedural issue I have. This I-D patches three other RFCs, which over the time may become an issue. I would rather see each document having their own bis and RFC4291 update being the master on all of these updates. I recon it might be awfully late for this, though. ** Section 4.1: NEW: | 8 | 4 | 4 | 8 | 8 | 64 | 32 | +--------+----+----+--------+--------+----------------+----------+ |11111111|flgs|scop|reserved| plen | network prefix | group ID | +--------+----+----+--------+--------+----------------+----------+ ^^^^^^^^ Shouldn't this also be align with other NEW formats? Others have a new set of "flgs" + "rsvd" here. ** In all proposed updated address formats we seem to have the following: | 8 | 4 | 4 | 4 |.. +--------+----+----+----+----+--------+----------------+----------+ |11111111|flgs|scop|flgs|.. | +--------+----+----+----+----+--------+----------------+----------+ ^^^^^^^^^^^^^^ I find this confusing having two distinct sets of "flgs". Why not concatenate that to one 12 bits field? Or at least name the latter "flgs" differently? Either way current statements like in Section 4.2 +-+-+-+-+ flgs is a set of four flags: |X|R|P|T| +-+-+-+-+ are wrong, since there are now two sets of "flgs" that sum up to eight flags. Therefore I would propose for example the following format: | 8 | 12 | .. +--------+----+----+----+----+--------+----------------+----------+ |11111111|flgs_and_scop | .. | +--------+----+----+----+----+--------+----------------+----------+ Then describe the "flgs_and_scop" as 11 7 3 0 +-+-+-+-+-+-+-+-+-+-+-+-+ |X|R|P|T| scope |r|r|r|r| +-+-+-+-+-+-+-+-+-+-+-+-+ where "rrrr" are for future assignment as additional flag bits. Or alternatively: | 8 | 4 | 4 | 4 |.. +--------+----+----+----+----+--------+----------------+----------+ |11111111|flgs|scop|newf|.. | +--------+----+----+----+----+--------+----------------+----------+ where "newf" are for future assignment as additional flag bits. ** Section 5 IANA Considerations: This document may require IANA updates. However, at this point it is not clear exactly what these updates may be. I find this statement rather sloppy. At least the authors should give a try listing possible impacts & updates. - Jouni From jouni.nospam@gmail.com Mon Feb 10 02:41:24 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C42B1A07E9 for ; Mon, 10 Feb 2014 02:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxwacZU9gFE3 for ; Mon, 10 Feb 2014 02:41:21 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id AEA161A07F5 for ; Mon, 10 Feb 2014 02:41:20 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id n15so4689969lbi.11 for ; Mon, 10 Feb 2014 02:41:20 -0800 (PST) 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; bh=iuLtTtflyQapuv60CbX/T6+aoFi6JaLEGEuBxZomv28=; b=wBPI1deml+9erALLxeTA18wRm1kqwrOhd85c9t3wARjUMV4gnIrXDknlRxBACzWkEd a3xaQyre+Q8qWySrf269NLhCLIKZOBcQaV2CIJ+8UgPWo077dmZeIcBzRL56pb6ILMGB loUISoEpWo7suqc/s3CQXYO/bm2CpoF579f6xg0kk1Noa//DcbFOFALcqSuDntx9ET/G IrEDfNK88mmr+Pr1i2IDCwIYsRC0JMtO4a4tuYJZvjHa78ELMWVi3Pa3TgtRJLSy+cI6 frt7wHBm3DOvLu2XweuyVNFHrVc5snQLl6k4Kn5HZLzNn54Lbi/qrMaPnVNxwfqiz8Sz t1Kg== X-Received: by 10.152.229.225 with SMTP id st1mr21677769lac.2.1392028879821; Mon, 10 Feb 2014 02:41:19 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:a0bf:a610:ae3e:9851? ([2001:1bc8:101:f101:a0bf:a610:ae3e:9851]) by mx.google.com with ESMTPSA id k1sm15348991lbc.5.2014.02.10.02.41.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 02:41:19 -0800 (PST) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Comments on draft-ietf-6man-multicast-scopes-02 Message-Id: Date: Mon, 10 Feb 2014 12:41:17 +0200 To: IPv6 IPv6 List , draft-ietf-6man-multicast-scopes@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 10:41:24 -0000 Sorry for being late with my comments but here we go anyway. I think this document is almost ready. Few comments/questions though. ** In Section 3: NEW: o The boundaries of zones of a scope are defined by the IPv6 addressing architecture [RFC4291]. Ok.. this is confusing since it is *this* I-D that updates RFC4291 with a new Realm-scope aware boundary, thus RFC4291 would eventually point back to this I-D. So while the above change is correct it definitely is confusing. Just like with draft-ietf-6man-multicast-addr-arch-update I see a need for RFC4291bis, where Section 1 like enhancements would belong to rather than stacking up I-Ds that patch things here and there. Again I recon it might be too late for this, though. ** Section 5 What would go under the other scopes than 3? Shouldn't we say at least something about the possible future use of those? Will they also list RFCs? ** Section 7 I don't think it is sufficient just to refer to RFC4291 (almost non existent) security considerations. For example there should be a reference to RFC4007 which actually has text related to security considerations of boundaries and scopes. - JOuni From fernando@gont.com.ar Mon Feb 10 03:37:17 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF811A080B for ; Mon, 10 Feb 2014 03:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovLz3DXughkc for ; Mon, 10 Feb 2014 03:37:14 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF531A0877 for <6man@ietf.org>; Mon, 10 Feb 2014 03:37:14 -0800 (PST) Received: from [2001:5c0:1000:a::605] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WCpAf-000890-4u; Mon, 10 Feb 2014 12:37:06 +0100 Message-ID: <52F8B625.4070000@gont.com.ar> Date: Mon, 10 Feb 2014 08:21:09 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "C. M. Heard" , 6MAN <6man@ietf.org> Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <52F13D1D.9050800@gont.com.ar> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 11:37:17 -0000 On 02/09/2014 04:35 PM, C. M. Heard wrote: > > In the absence of a strong argument to the contrary, it seems to me > that the existing Destination Options header can be used to do > exactly the same thing as the proposed UEH. In other words, I agree > with Jen's comments. There are two issues here: 1) Your proposed outcome still means that we should still do something about this issue. i.e., state "New Next Headers will never be specified. And hereby we deprecate RFC6465's section on the unified format". 2) I wonder whether we really want to close the door to new extension headers. After all, new ext header will not be more harmful than the existing ones (in terms of the issues that have been discussed a number of times on this and other lists). [....] >> Let's say that, tomorrow, the IETF standardizes the GTP (Google >> Transport Protocol :-)), and it is assigned the Next Header value 0xFF >> (I'm assuming this one is not currently assigned, bbut I'm not checking >> the IANA registry right now). >> >> Say a middle-box receives a packet that simply encapsulates GTP in IPv6, >> and that middlebox does not yet support GTP. If the middle-box tries to >> interpret the GTP header as in RFC6465, it will certainly fail. >> >> The reason? -- RFC 6465 implicitly assumes that every new Next Header >> will employ the RFC6465 format. This may be sensible for new *extension >> headers*, but certainly not for new transport protocols. >> >> And since transport protocols and extension headers share the same >> namespace (see RFC7045), this is a problem. > > All this is true. The implication is that the middlebox must stop > parsing the header chain when it encounters an unknown Next Header. Agreed. But what we want to achieve is that they don't need to -- particularly when the unknown Next Header is an extension. > In more detail, I see the three cases: > > 1.) The middlebox encounters an ESP Next Header, signalling that an > encrypted payload follows. In that case it stops parsing the > header chain and applies its policy for encrypted payloads. Agreed. IN this case, ESP would be the "upper layer protocol" as per our definition in RFC 7112. > 2.) The middlebox encounters a Next Header corresponding to a known > transport protocol. In that case it may perform filtering > actions specific to that transport protocol (and of course may > continue parsing into the transport header in order to do so). The problem is that, right now, a middle-box cannot tell whether it's in the presence of a new transport protocol, or an extension header. This is the ambiguity we should get rid off. RFC 7045 tackles part of the problem (ie., for known ext headers)... but there's still the ambiguity for new ones. > > 3.) The middlebox encounters an unknown Next Header value. In that > case it stops parsing the header chain and applies its policy > for packets with unknown Next Header values. In order to comply > with RFC 7045, it MUST be possible to configure the policy to > allow such packets, but the default MAY be to drop them. A > high-quality implementation would allow the policy to be > configured individually for each unknown Next Header value. > > I agree that there are use cases where it is important for a middlebox > to clearly distinguish between an unknown extension header and an > unknown transport protocol. Agreed. This is th key point. [...] >> What's clear is that the only way in which RFC6465 can possibly work is >> if the middle-box has some a-priori knowledge that what is being >> encapsulated follows RFC6465 -- whether as a result of a reserved range >> (as originally proposed by Hagen) or by specifying a single UEH, and >> then encoding all possible future "extension headers" as subtypes of UEH. > > A third possibility would be to go a step further than RFC 6564 and > ban new extension headers outright, insisting that a Destination > Option be used instead. Yes. That is among the options. I'm not sure that I'd side with this one. But certainly, any of the three options that have been discussing (the one currently documented in our I-D, Hagen's, or this one) are better than the current state of affairs. Thanks! 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 mohamed.boucadair@orange.com Mon Feb 10 05:37:21 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7931A06DA for ; Mon, 10 Feb 2014 05:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylfzXP47qqXm for ; Mon, 10 Feb 2014 05:37:19 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 1C44D1A05FA for ; Mon, 10 Feb 2014 05:37:19 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 3CC882AC6EA; Mon, 10 Feb 2014 14:37:18 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 0ABB7158059; Mon, 10 Feb 2014 14:37:18 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Mon, 10 Feb 2014 14:37:18 +0100 From: To: Jouni Korhonen , IPv6 IPv6 List , "draft-ietf-6man-multicast-addr-arch-update@tools.ietf.org" Date: Mon, 10 Feb 2014 14:37:14 +0100 Subject: RE: Comments on draft-ietf-6man-multicast-addr-arch-update-02 Thread-Topic: Comments on draft-ietf-6man-multicast-addr-arch-update-02 Thread-Index: Ac8mQdIXX0mj9fyVQKK+xQ+3ehB2BgAIVPiA Message-ID: <94C682931C08B048B7A8645303FDC9F36F4BFE361A@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.19.63615 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 13:37:21 -0000 Hi Jouni, Thank you for the comments.=20 Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Jouni Korhonen [mailto:jouni.nospam@gmail.com] >Envoy=E9=A0: lundi 10 f=E9vrier 2014 10:24 >=C0=A0: IPv6 IPv6 List; draft-ietf-6man-multicast-addr-arch- >update@tools.ietf.org >Objet=A0: Comments on draft-ietf-6man-multicast-addr-arch-update-02 > >Sorry being a bit late but I had a read of this document. > >** Some nits: > >s/[ADDRARCH]/[RFC4291] [Med] Will be fixed. Thanks. > >** While I agree this document is needed there is a general procedural >issue I have. This I-D patches three other RFCs, which over the time >may become an issue. I would rather see each document having their >own bis and RFC4291 update being the master on all of these updates. I >recon it might be awfully late for this, though. [Med] The point was raised in the mailing list (http://www.ietf.org/mail-ar= chive/web/ipv6/current/msg17811.html) and also during the f2f meeting (e.g.= , slide 4 of http://www.ietf.org/proceedings/88/slides/slides-88-6man-6.pdf= ). As no comment was raised during the meeting (http://www.ietf.org/proceed= ings/88/minutes/minutes-88-6man), we maintained the changes in the same doc= ument. > >** Section 4.1: > > NEW: > > | 8 | 4 | 4 | 8 | 8 | 64 | 32 = | > +--------+----+----+--------+--------+----------------+----------= + > |11111111|flgs|scop|reserved| plen | network prefix | group ID = | > +--------+----+----+--------+--------+----------------+----------= + > ^^^^^^^^ > >Shouldn't this also be align with other NEW formats? Others have a new set >of "flgs" + "rsvd" here. [Med] Agree. This point is also raised by Tatuya. Will be fixed.=20 > >** In all proposed updated address formats we seem to have the following: > > | 8 | 4 | 4 | 4 |.. > +--------+----+----+----+----+--------+----------------+----------+ > |11111111|flgs|scop|flgs|.. | > +--------+----+----+----+----+--------+----------------+----------+ > ^^^^^^^^^^^^^^ > >I find this confusing having two distinct sets of "flgs". Why not >concatenate >that to one 12 bits field? Or at least name the latter "flgs" differently? [Med] We are considering using "Flag Fied 1" and "Flag Field 2". > >Either way current statements like in Section 4.2 > > +-+-+-+-+ > flgs is a set of four flags: |X|R|P|T| > +-+-+-+-+ > >are wrong, since there are now two sets of "flgs" that sum up to eight >flags. [Med] This will be clarified in the new version (i.e., this "flgs" will be = renamed to "ff1"). Thanks.=20 > > >Therefore I would propose for example the following format: > > | 8 | 12 | .. > +--------+----+----+----+----+--------+----------------+----------+ > |11111111|flgs_and_scop | .. | > +--------+----+----+----+----+--------+----------------+----------+ > >Then describe the "flgs_and_scop" as > > 11 7 3 0 > +-+-+-+-+-+-+-+-+-+-+-+-+ > |X|R|P|T| scope |r|r|r|r| > +-+-+-+-+-+-+-+-+-+-+-+-+ > >where "rrrr" are for future assignment as additional flag bits. > >Or alternatively: > > | 8 | 4 | 4 | 4 |.. > +--------+----+----+----+----+--------+----------------+----------+ > |11111111|flgs|scop|newf|.. | > +--------+----+----+----+----+--------+----------------+----------+ > >where "newf" are for future assignment as additional flag bits. [Med] The current approach we are discussing with Stig is to use ff1 and ff= 2. > > > >** Section 5 IANA Considerations: > > This document may require IANA updates. However, at this point it is > not clear exactly what these updates may be. > >I find this statement rather sloppy. At least the authors should >give a try listing possible impacts & updates. [Med] That text will be removed.=20 > >- Jouni From rja.lists@gmail.com Mon Feb 10 05:54:22 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113941A02C9 for ; Mon, 10 Feb 2014 05:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zy4qzZCNdQeI for ; Mon, 10 Feb 2014 05:54:18 -0800 (PST) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id B141E1A083F for ; Mon, 10 Feb 2014 05:54:18 -0800 (PST) Received: by mail-qa0-f47.google.com with SMTP id j5so9392176qaq.20 for ; Mon, 10 Feb 2014 05:54:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version; bh=LVUZEFNRDDO0DgzuKbe1qUG8p4HWQFc7MZXz+q9pXyQ=; b=kC4mZ06MNSBa7y7TBJCfxUeBWYEzAQ9RLxLOiiguGYoBqF2fk52jgPc8O6Smd2rGT4 AQ8dKBqb4utwANXjaFIPmtTPB/dY+Puc3hdsoShH7eOy/PVRM9ZHpLev3omQYHUTYtXx XQeWNEl3Fyl1ndqDmFU1HTW56Irsu5neMjH8fv6DYzP7X143VU9egvwjvhOcc6EbMqZt FEye5sbax5kGyPkCfGXWBX9mwU+A0KOIAeo9x3PxWp14ROuH2eumsrl1F0od5bWKCNXr PhODrayxjOqBvxqqf/PHEhCyF++4ZsSwsyyJ5g3//KEfqNbwRFAJw1CybPWurtSzoWbC d1/A== X-Received: by 10.140.82.175 with SMTP id h44mr45317831qgd.68.1392040458517; Mon, 10 Feb 2014 05:54:18 -0800 (PST) Received: from [10.30.20.14] (pool-173-79-6-58.washdc.fios.verizon.net. [173.79.6.58]) by mx.google.com with ESMTPSA id p10sm10211482qag.8.2014.02.10.05.54.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 05:54:18 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 10 Feb 2014 08:54:23 -0500 Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers To: ipv6@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 13:54:22 -0000 At Thursday, 6th February 2014 07:21:49 -0500, Thomas Narten wrote: > At Wed, 05 Feb 2014 01:25:03 -0300, Fernando Gont wrote: > > 1) If this problem remains un-addressed, then it's impossible to > > differentiate between new upper-layer headers (e.g. a new transport > > protocol) and new extension headers. Since such new extension headers > > might be leveraged for malicious purposes, the end-result is that > > middle-boxes are going to block *everything* (see RFC7045), > > which means: > > > > + no new extension headers > > + no new transport protocols > > > > ... so I think we really don't want to go there. > > But we are already there. Folk won't deploy anything other than > TCP/UDP because NAT won't deal with it. That has already been reality > and is the reason that other or new transport protocols appear to be > virtually undeployable today. > > Reality is that existing middleboxes tend to process what they > understand and have been explicitely coded to deal with. They just > punt on anything else because that is the easiest/safest thing to do. > > I see little that we can do to change that. > > Thomas I agree with Thomas Narten's analysis. The deployed situation perhaps isn't ideal, but the IETF ought to hew to the deployed reality. Today's reality is that the Internet is very unlikely to deploy any new transport protocol(s) or any new IPv6 extension headers. My own preference (has been and) would be to outright ban all new IPv6 Extension Headers -- insisting that future IPv6 extensions be specified as options within the existing Destination Options header or Hop-by-Hop Options header. ENTERPRISE/OPERATOR FIREWALLS: I understand that some residential users have (or want to have) pure/direct IPv6 connectivity without any firewalls/middleboxes. (Many folks that I know have some form of home firewall. Many of those folks demand NAT for the perceived security benefits. At a previous employer of mine, IPv6 NAT/NAPT was the single most commonly requested IPv6 feature -- by a wide margin.) However, every enterprise/corporate/similar IPv6 user (or planned future IPv6 user) that I can identify is staying that a full firewall is a non-negotiable absolute requirement for ALL Internet-related connectivity. The handful of content providers that I've talked with also will not permit their content servers to be directly connected -- all are using some form of firewall. [Aside: Quite commonly, the firewall device also acts as a site's VPN termination point (e.g. for IPsec-based or TLS-based VPNs).] NEWER TRANSPORT PROTOCOLS: Few, if any, IP firewalls support SCTP at present. Ditto for NORM, although NORM can traverse some firewalls because NORM usually runs over UDP. I'm not certain why SCTP has little or no deployment, but one certainly wonders how SCTP could be deployed widely -- given that most firewalls simply drop all SCTP traffic. My sense is that any new transport protocol probably should use UDP framing (or UDP encapsulation) if it wants to be easily and widely deployed. There is probably more mileage to be had from further TCP optimisation/ extension than from a new reliable transport protocol. HARDWARE PACKET PARSERS: The handful of wire-speed packet parsers that I am familiar with all are built out of ASICs. The set of options/headers/protocols that those packet parsers can process in hardware are fixed at the time that the Verilog of the ASIC is frozen -- and will not change during the lifetime of that ASIC's deployment. Any unrecognised "Next Header" value likely will cause either (a) packet to be dropped, (b) packet to be processed without further parsing, or (c) packet to be kicked to a CPU-based (or NP-based) slow-path packet handler. Of those three, alternative (a) is the most likely to be seen in the deployed Internet. With improvements in FPGAs, one certainly can imagine that some future generation of wire-speed hardware packet parsers would be built using FPGAs. Those could, in principle at least, be updated after deployment. It is unclear to me whether such updates would be supplied by the manufacturer or how many users would deploy updates that are supplied by the manufacturer. BOTTOM LINE: My perception is that this ship sailed several years ago, and that it is either impossible or nearly impossible to deploy any new IPv6 Extension Header (although IPv6 options carried in existing headers still seem possible) or any new transport-layer protocol using different framing from TCP/UDP. Yours, Ran Atkinson From fernando@gont.com.ar Mon Feb 10 06:46:01 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11141A0846 for ; Mon, 10 Feb 2014 06:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZSXmlpqmsPU for ; Mon, 10 Feb 2014 06:45:55 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 7828C1A02E1 for ; Mon, 10 Feb 2014 06:45:55 -0800 (PST) Received: from [2001:5c0:1000:a::81f] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WCs7N-0004Ij-04; Mon, 10 Feb 2014 15:45:53 +0100 Message-ID: <52F8E610.6000504@gont.com.ar> Date: Mon, 10 Feb 2014 11:45:36 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: RJ Atkinson , ipv6@ietf.org Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers References: In-Reply-To: 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.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 14:46:02 -0000 Hi, Ran, On 02/10/2014 10:54 AM, RJ Atkinson wrote: > > I agree with Thomas Narten's analysis. > > The deployed situation perhaps isn't ideal, but the IETF ought to > hew to the deployed reality. FIWIW, that's the bottom-line of my reasoning. > Today's reality is that the Internet > is very unlikely to deploy any new transport protocol(s) or any new > IPv6 extension headers. My own preference (has been and) would be > to outright ban all new IPv6 Extension Headers -- insisting that > future IPv6 extensions be specified as options within the existing > Destination Options header or Hop-by-Hop Options header. That's certainly among the options -- and is an acceptable outcome: if you receive a packet that has an unrecognized next header, treat it as a new transport protocol (and probably drop it). But we currently assume that there might be new extensions, and that we can parse unrecognized headers -- which we cannot. > ENTERPRISE/OPERATOR FIREWALLS: [...] I fully agree with all your observations. > NEWER TRANSPORT PROTOCOLS: > > Few, if any, IP firewalls support SCTP at present. Ditto for NORM, > although NORM can traverse some firewalls because NORM usually runs > over UDP. I'm not certain why SCTP has little or no deployment, Apparently, there's a fair share of SCTP deployment, albeit not for public Internet services. And, in many cases, SCTP is being encapsulated on top of UDP. > BOTTOM LINE: > > My perception is that this ship sailed several years ago, and that it > is either impossible or nearly impossible to deploy any new IPv6 > Extension Header (although IPv6 options carried in existing headers > still seem possible) or any new transport-layer protocol using different > framing from TCP/UDP. FWIW, Extension Headers seem to be widely dropped. See e.g.: (Tim Chown has obtained similar results). However, we still need to determine when in the network such packet drops happen. What I would expect is that: 1) We clarify that despite RFC 6465, no middle-box can parse unrecognized Next Headers. i.e., no middle-box could parse a new Extension Header, unless the middle-box explicitly supports it. Then, we either provide a way for them to parse unknown headers (as in our UEH I-D), or ban new extension headers once and for all -- and we forget about this. 2) Even with the current data, it seems that employing extension headers for protocol extensions is not really a viable option in the real world. That is, if we were to specify a new option (even if it is to be included in a Dst Options header), that would lead to packet drops (rather than "ignore the extensions/options"). The conclusion would be that, for the general case, "think twice before relying on Ext Headers, then don't". And this should be documented, so that any protocol design that means to use EHs is aware of the fact that it probably won't work as expected in the deployed world. 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 jouni.nospam@gmail.com Mon Feb 10 08:05:26 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4481A086D for ; Mon, 10 Feb 2014 08:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4f4Q9w0hxW9 for ; Mon, 10 Feb 2014 08:05:24 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C91121A0320 for ; Mon, 10 Feb 2014 08:05:23 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id u14so5002509lbd.1 for ; Mon, 10 Feb 2014 08:05:22 -0800 (PST) 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; bh=ImzJfAg3vx1LvrvNWUo3lHllsNNxWreC3Acj4tigYUY=; b=yQGGeTb6SuQarRQAkJpuSlTridgBzvcr+4KkbPOxQkUJQGUHp4/lxxY7tuocZavzaS gg+5M4mnNmOBvNedxaUHyn4ZCYti5myD1g6vzwku3AEQIWBIl8HPKCKnaQ3z//A1wVjP HqBBgLngp4Y5G6rLtBOQQydK079zL0Mm/KpXUPJphwK/sCaTPr6QiCfDus9Vc4ZnUdOu mzbGprIAfFmflmeERnws1848xgtuSNyrCflTkUfzEjJteEbEkXe6KG+jAaa6a2HHuq+9 PBOo3vf31oY5BJeqtPohMpewBqmH1a68n3nlsQ4/MGddKeWIKsH9eOyFAO6RxMwhZpTO eD1Q== X-Received: by 10.152.205.11 with SMTP id lc11mr22695667lac.29.1392048322846; Mon, 10 Feb 2014 08:05:22 -0800 (PST) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id 10sm22915354lan.5.2014.02.10.08.05.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 08:05:22 -0800 (PST) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: comments on draft-ietf-6man-enhanced-dad-04 Message-Id: <78AE6729-1A26-48EA-BD31-FBBDE85C829E@gmail.com> Date: Mon, 10 Feb 2014 18:05:21 +0200 To: draft-ietf-6man-enhanced-dad@tools.ietf.org, IPv6 IPv6 List Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 16:05:26 -0000 Authors, I have a read on this document. I find it good and informative. Few=20 comments and questions inline. ** Abstract o There is no mention that this document updates RFC4861 and RFC4862. ** Section 1 specified in [RFC4862]. Failure also includes if the Target Address is optimistic. Optimistic DAD is specified in [RFC4429]. o I do not understand the sentence "Failure also includes if the Target Address is optimistic." Some word missing there? ** Section 3.2 This solution requires no protocol changes. This solution SHOULD be enabled by default, and MUST be a configurable option. o I would clarify here, just to be clear on the context, that the above MUST applies only if the layer 2 has an ability to detect looped back messages. Proposed text: This solution requires no protocol changes. This solution SHOULD be enabled by default, and MUST be a configurable option if the layer 2 technology provides means for detecting loopback messages on an interface circuit. ** Section 4 SEND. See more details in the Impact on SEND section. Since a nonce ^^^^^^^^^^^^^^^^^^^^^^^ o I would point explicitly to the section number as well. o The algorithm description in the second paragraph is somewhat hard to follow. I had to read it quite many times.. On the other hand, the algorithm description in Section 4.2 is far more readable. Consider having the algorithm description only in one place. ** Section 4.2 The MAX_MULTICAST_SOLICIT number of NS(DAD) messages sequence continues until the stop condition is reached. o Or manual administrative actions are taken, right? o The stop condition and ending the probing means the interface moves the Target Address to assigned state, right? I would say that=20 explicitly. ** Section 4.4 detecting looped back ND messages. If this document updates [RFC4862], SEND should be updated to integrate with the Enhanced DAD algorithm. A minor update to SEND would be to explicitly mention o "If this document updates.." well it does. Propose changing the text = to something like "Since this document.." o Why there is no proposal for those "minor" SEND updates? ** Section 4.5 The following text is added to [RFC4862]. o Added where in RFC4862? Propose an explicit place. o The added text should probably have a reference to this document. ** Section 4.6 o Changes where exactly in RFC4861? Propose an explicit place. o The added text should probably have a reference to this document. ** Section 6 algorithm. SEND is recommended for this exploit. For any mitigation o I would say SEND is not recommend for this exploit rather SEND is = recommended to circumvent this exploit. ** Section 9 o Obsolete normative reference to RFC1247 (obsoleted by RFC1583) o No reference to RFC2119 (also there is no typical RFC2119 boilerplate = text) o draft-ietf-6man-impatient-nud -> RFC7048 - Jouni= From rdroms.ietf@gmail.com Mon Feb 10 08:18:22 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C901A06EE for ; Mon, 10 Feb 2014 08:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOtcrjgGMNhy for ; Mon, 10 Feb 2014 08:18:19 -0800 (PST) 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 857021A06DE for ; Mon, 10 Feb 2014 08:18:19 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id w8so9707284qac.36 for ; Mon, 10 Feb 2014 08:18:19 -0800 (PST) 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=epyxw8SCBTPwYZbequSpbvf7F6H45nKU5nITBWXjX3U=; b=lCEm/zB4JLDojAkums9eFb5rBggSS9W7nvFYqbT4gr8hS9AWgg6kSgnMINqOh9wZp8 gkxvFt0fFuPef9gIs5w/Xzf3iiBgFsxeRI92ND4Sah1KLfYEITJhl2RfnA6+e55eAPuA 15ljvspnvmAlFJ4oL9IQ+mWp4/2IcngG5hkhjcfXEK0cb+t6eApwlbkfj2M1CImUlf5s 9r2tSkDeRZuUo0OcVNwStki3K8dt+BSRXzkW/jvrCQRA4q5HtcCIAmOu7xHqYHcvhIVp rUVHyMVXlkJKqZRgDOzRB9jyDEtCN7TvQhjL2Apa2DTHasu5cq6c5bkB8bv9ds7V30RY jk6w== X-Received: by 10.140.94.74 with SMTP id f68mr46436815qge.64.1392049098063; Mon, 10 Feb 2014 08:18:18 -0800 (PST) Received: from ?IPv6:2001:420:2c52:1316:a12a:883:79cf:6178? ([2001:420:2c52:1316:a12a:883:79cf:6178]) by mx.google.com with ESMTPSA id a5sm44053117qae.2.2014.02.10.08.18.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 08:18:15 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Comments on draft-ietf-6man-multicast-scopes-02 From: Ralph Droms In-Reply-To: Date: Mon, 10 Feb 2014 11:18:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Jouni Korhonen X-Mailer: Apple Mail (2.1510) Cc: draft-ietf-6man-multicast-scopes@tools.ietf.org, IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 16:18:22 -0000 On Feb 10, 2014, at 5:41 AM 2/10/14, Jouni Korhonen = wrote: > Sorry for being late with my comments but here we go anyway. >=20 > I think this document is almost ready. Few comments/questions > though. >=20 > ** In Section 3: >=20 > NEW: >=20 > o The boundaries of zones of a scope are defined by the IPv6 > addressing architecture [RFC4291]. >=20 > Ok.. this is confusing since it is *this* I-D that updates RFC4291 > with a new Realm-scope aware boundary, thus RFC4291 would eventually > point back to this I-D. So while the above change is correct it > definitely is confusing. How about: o The boundaries of zones of a scope are defined by the IPv6 addressing architecture [RFC4291] and updated by this document. >=20 > Just like with draft-ietf-6man-multicast-addr-arch-update I see a > need for RFC4291bis, where Section 1 like enhancements would > belong to rather than stacking up I-Ds that patch things here and > there. Again I recon it might be too late for this, though. In my opinion, it would be fine to start on an RFC4291bis now. I would = strongly object to holding up this document for that effort, as the = definition of scop 3 is needed now for MPL. >=20 > ** Section 5 >=20 > What would go under the other scopes than 3? Shouldn't we say at > least something about the possible future use of those? Will they > also list RFCs?=20 RFC 4291 explicitly leaves the other scopes "(unassigned)". It would be = out of scope for this document to say more about those scopes than RFC = 4291. > ** Section 7 >=20 > I don't think it is sufficient just to refer to RFC4291 (almost non > existent) security considerations. For example there should be a > reference to RFC4007 which actually has text related to security > considerations of boundaries and scopes. Good point. I suggest: 7. Security Considerations This document has no security considerations beyond those in RFC 4007 [RFC4007] and RFC 4291 [RFC4291]. - Ralph >=20 > - JOuni > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From jouni.nospam@gmail.com Mon Feb 10 09:14:47 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF3C1A0386 for ; Mon, 10 Feb 2014 09:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8blv9aJkRg9 for ; Mon, 10 Feb 2014 09:14:44 -0800 (PST) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7905F1A0322 for ; Mon, 10 Feb 2014 09:14:44 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id b8so5052584lan.32 for ; Mon, 10 Feb 2014 09:14:43 -0800 (PST) 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=h/IdsfwHA+3/LenP0SJiH54LseCWBDcMefaLR8goBB4=; b=qqFf+baxMaUUcg48O3VCbBQTuercmX1MTr1JpzHVDO7Et9iJ8BXAutJJ4GlrXkia77 doeHqlUpjykeYXyM5UrwoKTXmbyGfZ083uKne7OOST1ZaeTlpjk/DG+IakiRjvPESOxw 1lv9vmXo8YIWPD8y7UNWZIwws6IxMgVrSdvyV8bHscNtShCKK+tP6jBWmaQRmusQPFrh 57ykU2INNxVHYG4QNo9Ywsgx7kENU7ktB4JWWNYDjLoSZpeiXeaQ9POoTgrF2NJJ6zuW j6yt9VupNKOC9PR4l0+RIqIv3iy5JpKTCYrKJ8Flrr5AZ29xxXROsdet9oUxCHd5ieAH oG1g== X-Received: by 10.152.42.196 with SMTP id q4mr2073021lal.52.1392052483664; Mon, 10 Feb 2014 09:14:43 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:9530:4b2c:f90f:fc4e? ([2001:1bc8:101:f101:9530:4b2c:f90f:fc4e]) by mx.google.com with ESMTPSA id pz10sm16439738lbb.10.2014.02.10.09.14.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 09:14:39 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Comments on draft-ietf-6man-multicast-scopes-02 From: Jouni Korhonen In-Reply-To: Date: Mon, 10 Feb 2014 19:14:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ralph Droms X-Mailer: Apple Mail (2.1510) Cc: draft-ietf-6man-multicast-scopes@tools.ietf.org, IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 17:14:47 -0000 On Feb 10, 2014, at 6:18 PM, Ralph Droms wrote: >=20 > On Feb 10, 2014, at 5:41 AM 2/10/14, Jouni Korhonen = wrote: >=20 >> Sorry for being late with my comments but here we go anyway. >>=20 >> I think this document is almost ready. Few comments/questions >> though. >>=20 >> ** In Section 3: >>=20 >> NEW: >>=20 >> o The boundaries of zones of a scope are defined by the IPv6 >> addressing architecture [RFC4291]. >>=20 >> Ok.. this is confusing since it is *this* I-D that updates RFC4291 >> with a new Realm-scope aware boundary, thus RFC4291 would eventually >> point back to this I-D. So while the above change is correct it >> definitely is confusing. >=20 > How about: >=20 > o The boundaries of zones of a scope are defined by the IPv6 > addressing architecture [RFC4291] and updated by this document. Wfm. >> Just like with draft-ietf-6man-multicast-addr-arch-update I see a >> need for RFC4291bis, where Section 1 like enhancements would >> belong to rather than stacking up I-Ds that patch things here and >> there. Again I recon it might be too late for this, though. >=20 > In my opinion, it would be fine to start on an RFC4291bis now. I = would strongly object to holding up this document for that effort, as = the definition of scop 3 is needed now for MPL. >=20 >>=20 >> ** Section 5 >>=20 >> What would go under the other scopes than 3? Shouldn't we say at >> least something about the possible future use of those? Will they >> also list RFCs?=20 >=20 > RFC 4291 explicitly leaves the other scopes "(unassigned)". It would = be out of scope for this document to say more about those scopes than = RFC 4291. Since this document establishes a new registry, we at least need to define the guidelines on how future assignments are to be made as per RFC5226. >=20 >> ** Section 7 >>=20 >> I don't think it is sufficient just to refer to RFC4291 (almost non >> existent) security considerations. For example there should be a >> reference to RFC4007 which actually has text related to security >> considerations of boundaries and scopes. >=20 > Good point. I suggest: >=20 > 7. Security Considerations >=20 > This document has no security considerations beyond those in RFC = 4007 > [RFC4007] and RFC 4291 [RFC4291]. Wfm. - JOuni >=20 > - Ralph >=20 >>=20 >> - JOuni >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 From stig@venaas.com Mon Feb 10 10:25:01 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFAF1A00EE for ; Mon, 10 Feb 2014 10:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chW3y-f17uPH for ; Mon, 10 Feb 2014 10:24:58 -0800 (PST) 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 3508B1A01F1 for ; Mon, 10 Feb 2014 10:24:58 -0800 (PST) Received: from [IPv6:2001:420:301:1004:9c1c:c7c0:5307:24f8] (unknown [IPv6:2001:420:301:1004:9c1c:c7c0:5307:24f8]) by ufisa.uninett.no (Postfix) with ESMTPSA id 351498026; Mon, 10 Feb 2014 19:24:55 +0100 (CET) Message-ID: <52F91975.9060704@venaas.com> Date: Mon, 10 Feb 2014 10:24:53 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Jouni Korhonen , IPv6 IPv6 List , draft-ietf-6man-multicast-addr-arch-update@tools.ietf.org Subject: Re: Comments on draft-ietf-6man-multicast-addr-arch-update-02 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 18:25:01 -0000 Hi Jouni On 2/10/2014 1:23 AM, Jouni Korhonen wrote: > Sorry being a bit late but I had a read of this document. > > ** Some nits: > > s/[ADDRARCH]/[RFC4291] > > ** While I agree this document is needed there is a general procedural > issue I have. This I-D patches three other RFCs, which over the time > may become an issue. I would rather see each document having their > own bis and RFC4291 update being the master on all of these updates. I > recon it might be awfully late for this, though. I agree. I'm not sure what is the right thing to do here, I've also been wondering if what you say would be better. I've been asking this question several time, but I haven't really got much feedback. I wonder if it might be worth checking with the IESG or others to see what the best way is. It would be a big task updating those documents though. One way forward could be to publish this document soon, and then work on bis versions of those documents that may also include other improvements. > ** Section 4.1: > > NEW: > > | 8 | 4 | 4 | 8 | 8 | 64 | 32 | > +--------+----+----+--------+--------+----------------+----------+ > |11111111|flgs|scop|reserved| plen | network prefix | group ID | > +--------+----+----+--------+--------+----------------+----------+ > ^^^^^^^^ > > Shouldn't this also be align with other NEW formats? Others have a new set > of "flgs" + "rsvd" here. You're right, will update this. > ** In all proposed updated address formats we seem to have the following: > > | 8 | 4 | 4 | 4 |.. > +--------+----+----+----+----+--------+----------------+----------+ > |11111111|flgs|scop|flgs|.. | > +--------+----+----+----+----+--------+----------------+----------+ > ^^^^^^^^^^^^^^ > > I find this confusing having two distinct sets of "flgs". Why not concatenate > that to one 12 bits field? Or at least name the latter "flgs" differently? I'm thinking of maybe calling them flag field 1 and flag field 2 and use the names ff1 and ff2 in the diagram. Thoughts on that? > Either way current statements like in Section 4.2 > > +-+-+-+-+ > flgs is a set of four flags: |X|R|P|T| > +-+-+-+-+ > > are wrong, since there are now two sets of "flgs" that sum up to eight flags. So maybe say that flag field one contain 4 flags... > > Therefore I would propose for example the following format: > > | 8 | 12 | .. > +--------+----+----+----+----+--------+----------------+----------+ > |11111111|flgs_and_scop | .. | > +--------+----+----+----+----+--------+----------------+----------+ > > Then describe the "flgs_and_scop" as > > 11 7 3 0 > +-+-+-+-+-+-+-+-+-+-+-+-+ > |X|R|P|T| scope |r|r|r|r| > +-+-+-+-+-+-+-+-+-+-+-+-+ > > where "rrrr" are for future assignment as additional flag bits. > > Or alternatively: > > | 8 | 4 | 4 | 4 |.. > +--------+----+----+----+----+--------+----------------+----------+ > |11111111|flgs|scop|newf|.. | > +--------+----+----+----+----+--------+----------------+----------+ > > where "newf" are for future assignment as additional flag bits. I prefer this latter one. What do you think of flag field 1 and flag field 2 versus your proposal? > > > ** Section 5 IANA Considerations: > > This document may require IANA updates. However, at this point it is > not clear exactly what these updates may be. > > I find this statement rather sloppy. At least the authors should > give a try listing possible impacts & updates. Oops. This was true at some point and I guess we overlooked this later. I agree, it is pretty sloppy. I need to think a bit about this, Thanks for your comments. I intend to submit a new version before Friday. Stig > - Jouni > From brian.e.carpenter@gmail.com Mon Feb 10 11:06:39 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561BF1A03C9 for ; Mon, 10 Feb 2014 11:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4os0K8eE4-m for ; Mon, 10 Feb 2014 11:06:37 -0800 (PST) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4556A1A03A5 for ; Mon, 10 Feb 2014 11:06:37 -0800 (PST) Received: by mail-pb0-f41.google.com with SMTP id up15so6641095pbc.14 for ; Mon, 10 Feb 2014 11:06:36 -0800 (PST) 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=GtEnt1WRNCNXrKBvk/50YdTBR4Ow1fhuOA7HsL4DkTs=; b=fOFE66cYrcIqufRROV7PpogSGdlNgCj6w1Oi18OBAJxsVGlDgzuJIf1vW2F0K72AOK xlIDJ9yUgSE7+Zl/ZO+gq4p7qcMaAoNrTdkhZBhQMlrnQPjFM6/U+Yugh2EgfFXaiPQ+ EVQRXN6gPAbdn+lhjvTL0ssmyoHRfFJi/lExz6LX0SL76a8Ot/n/mLd+8Jjh88xI0Twg 5oSILfIO6/Y9xPm22Ctpfcm1YV0/FqPnAtLlW091WRXaOa++lHudtxEGOHF+pmQPO8BX xUErCIboipjMDrIo9Gs2myz38kVg04A+MqN5fu5wT0+iRBhrA6PZdDk8Qw9yITOWAcZf t4pg== X-Received: by 10.68.226.9 with SMTP id ro9mr39775219pbc.72.1392059196095; Mon, 10 Feb 2014 11:06:36 -0800 (PST) Received: from [192.168.178.23] (29.199.69.111.dynamic.snap.net.nz. [111.69.199.29]) by mx.google.com with ESMTPSA id yo9sm117125994pab.16.2014.02.10.11.06.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 11:06:34 -0800 (PST) Message-ID: <52F9233A.1080304@gmail.com> Date: Tue, 11 Feb 2014 08:06:34 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers References: In-Reply-To: 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.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 19:06:39 -0000 On 11/02/2014 02:54, RJ Atkinson wrote: > At Thursday, 6th February 2014 07:21:49 -0500, Thomas Narten wrote: >> At Wed, 05 Feb 2014 01:25:03 -0300, Fernando Gont wrote: >>> 1) If this problem remains un-addressed, then it's impossible to >>> differentiate between new upper-layer headers (e.g. a new transport >>> protocol) and new extension headers. Since such new extension headers >>> might be leveraged for malicious purposes, the end-result is that >>> middle-boxes are going to block *everything* (see RFC7045), >>> which means: >>> >>> + no new extension headers >>> + no new transport protocols >>> >>> ... so I think we really don't want to go there. >> But we are already there. Folk won't deploy anything other than >> TCP/UDP because NAT won't deal with it. That has already been reality >> and is the reason that other or new transport protocols appear to be >> virtually undeployable today. >> >> Reality is that existing middleboxes tend to process what they >> understand and have been explicitely coded to deal with. They just >> punt on anything else because that is the easiest/safest thing to do. >> >> I see little that we can do to change that. >> >> Thomas > > I agree with Thomas Narten's analysis. > > The deployed situation perhaps isn't ideal, but the IETF ought to > hew to the deployed reality. Today's reality is that the Internet > is very unlikely to deploy any new transport protocol(s) or any new > IPv6 extension headers. My own preference (has been and) would be > to outright ban all new IPv6 Extension Headers -- insisting that > future IPv6 extensions be specified as options within the existing > Destination Options header or Hop-by-Hop Options header. Not to dispute the facts of life as Thomas and Ran present them, but let me point out that this argument recurses. If we forbid additional Extension Headers (i.e. freeze things as they are listed in RFC 7045) but allow new Options, in a few years somebody will write Today's reality is that the Internet is very unlikely to deploy any new IPv6 Destination Options, because firewalls block unknown options. Guess what? This argument has been used against new IPv4 options since 1994 to my personal knowledge. (Hop-by-hop options are pretty much a dead duck anyway.) Just saying... Brian From fernando@gont.com.ar Mon Feb 10 11:30:28 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011191A05D8 for ; Mon, 10 Feb 2014 11:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTwaYsbp8XRr for ; Mon, 10 Feb 2014 11:30:25 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 477EB1A0128 for <6man@ietf.org>; Mon, 10 Feb 2014 11:30:24 -0800 (PST) Received: from [2001:5c0:1000:a::81f] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WCwXv-0002eT-Hq; Mon, 10 Feb 2014 20:29:36 +0100 Message-ID: <52F927E0.5080706@gont.com.ar> Date: Mon, 10 Feb 2014 16:26:24 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mark ZZZ Smith , Fernando Gont , Ole Troan Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <52F1B8CE.4070803@ericsson.com> <52F1BD1F.2080007@si6networks.com> <52F383A0.7030002@si6networks.com> <52F44A73.3000609@si6networks.com> <86BA587E-A7F8-47B9-AC74-98D3DB9A7E46@employees.org> <52F4DDC7.8070606@si6networks.com> <1391817989.71306.YahooMailNeo@web162204.mail.bf1.yahoo.com> In-Reply-To: <1391817989.71306.YahooMailNeo@web162204.mail.bf1.yahoo.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , "C. M. Heard" , Tim Chown , "6man@ietf.org" <6man@ietf.org>, Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 19:30:28 -0000 On 02/07/2014 09:06 PM, Mark ZZZ Smith wrote: >> >> If, say, tomorrow you come up with this shiny cool new Dst >> Opt-based extension for clients, then, from starters, you would >> have to think of a back-up plan, because in more than 40% cases >> your packets would get dropped just because of that extension. -- >> that's where we are right now. >> > > End-to-end crypto might the backup plan. Depends on what you mean by end-to-end crypto, and in what context. SSL/TLS for say, web servers and mailservers, fine. IPsec for the general case...mmm.. unlikely. Is there any plan for solving the authentication of nodes? Is everyone expected to get/buy a certificate? > I think it might be worth remembering that as per the IETF88 Plenary, > end-to-end encryption is the general direction, and that middle boxes > less effective/in-effective because of it. So putting a lot of time > and effort into facilitating them might be wasted effort. It's a 1-page to 5-page document (and that's including bolierplates). > I also think multipathing, to take advantage of smartphone/tablet's > multi-homing to the network will also mean middle boxes become less > effective/in-effective. IOS 7 is already using MPTCP for Siri for > example+. This is a comment from the URL you posted: > Yes, it works! Thanks Kristian. > However here in Italy 3G carriers filter out TCP options.. so SIRI gives > up and stops trying to use mptcp in the long run. 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 rja.lists@gmail.com Mon Feb 10 12:07:23 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65991A01FD for ; Mon, 10 Feb 2014 12:07:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziRq3SR7OGAN for ; Mon, 10 Feb 2014 12:07:21 -0800 (PST) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 479C61A0473 for ; Mon, 10 Feb 2014 12:07:21 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id c9so11275607qcz.41 for ; Mon, 10 Feb 2014 12:07:21 -0800 (PST) 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=CF5lalMeWYQ/3A2OJKfvDh5fY0Vh4F7r06y72PbGrhs=; b=nYm3ryetVABqR22lOeILA4kvYd3yjFSmzwSgxa8JuM7AZhoS3sf5nqPKtiF9oqcdrh 8Zr51ShH7vzbKG0Tk7ERH0L3tgp2Y2jBYGu2bfUkt+1LEKn2wvEON4vRBR8aSrHdjolp oV7TVydm0OH74WlMlqYoRaholjNYfjfb70KUX4mwB6T1X1ubIph7a2NIFYiQzdm3RXu3 6nOP+UBTKUi71ftQKJe7W36ONT1zm0+4EL9l7QB0bcB45ELvo67kgndSYYHOpiaPaP4b XiPjypUJ/yIQYVW+fdailVuCf2SsZhqvqPCSmISaNQaRLU00Q1MrYf9U0pKZnTFisb/Q xYdg== X-Received: by 10.140.92.213 with SMTP id b79mr47812302qge.108.1392062840950; Mon, 10 Feb 2014 12:07:20 -0800 (PST) Received: from [10.30.20.14] (pool-173-79-6-58.washdc.fios.verizon.net. [173.79.6.58]) by mx.google.com with ESMTPSA id 3sm45770442qan.15.2014.02.10.12.07.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 12:07:20 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers From: RJ Atkinson In-Reply-To: <52F9233A.1080304@gmail.com> Date: Mon, 10 Feb 2014 15:07:19 -0500 Content-Transfer-Encoding: 7bit Message-Id: <3A917394-1407-485B-BB08-6823D4A60985@gmail.com> References: <52F9233A.1080304@gmail.com> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1283) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 20:07:23 -0000 On 10 Feb 2014, at 14:06 , Brian E Carpenter wrote: > Not to dispute the facts of life as Thomas and Ran present them, > but let me point out that this argument recurses. > > If we forbid additional Extension Headers (i.e. freeze things > as they are listed in RFC 7045) but allow new Options, > in a few years somebody will write > > Today's reality is that the Internet is very unlikely to deploy > any new IPv6 Destination Options, because firewalls block > unknown options. (I am not sure, but I think Fernando might have posted this, or words like this, within the past week. :-) > Guess what? This argument has been used against new IPv4 options > since 1994 to my personal knowledge. Many ISPs have long declined to carry IPv4 transit packets that contain IPv4 options because all IPv4 options create interrupts to transit routers (i.e. easily exploited DDOS attack vector on the ISP and its routers). That reality creates a large barrier to deployment of anything in the global Internet. A key difference for IPv6, compared with IPv4 options, is that any options inside an IPv6 Destination Options header do NOT have the hop-by-hop behaviour (from the router's perspective), so they are not automatic easily-exploited DDOS attack vectors on the ISP or its routers. So there is a meaningful technical difference between the IPv4 history and the case of options in an IPv6 Destination Options header. As to firewalls, the IPv6 firewalls seem (on average) to be more configurable (e.g. often ICMPv6 has selective filters whereas, in the same box, ICMPv4 only has "drop all/accept all" filtering). Some sites deliberately will configure their firewalls to drop nearly everything optional (headers, transport protocols, flying geese, whatever). Nothing here will change that for such sites. Other sites configure their firewalls more selectively. What we do here might have an impact on those deployments and sites. > (Hop-by-hop options are pretty much a dead duck anyway.) Agreed. Many ISPs long ago decided that they will drop all IPv6 packets with the IPv6 Hop-by-Hop Header at their ingress border router. The "hop-by-hop" behaviour creates an easily exploited DDOS attack vector on the deployed infrastructure. Bad actors found that out years ago, and the ISPs responded shortly thereafter. BOTTOM LINE: I don't think that draft-gont-6man-ipv6-universal-extension-header is worth any time investment, because it can't change the deployed operational behaviour. If we bother to do anything, we ought to just acknowledge reality and say that no more IPv6 extension *headers* are allowed. Instead, options must be used. We also should note that options with hop-by-hop behaviour likely cannot be deployed reliably across the global public Internet. That would mean that any "new" NextHeader value would denote a transport-layer protocol (which I think also would be very difficult to deploy - I have never seen SCTP on-the-wire). Yours, Ran From rja.lists@gmail.com Mon Feb 10 12:17:43 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350BD1A0450 for ; Mon, 10 Feb 2014 12:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AN1PPt5JBNM8 for ; Mon, 10 Feb 2014 12:17:41 -0800 (PST) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA251A01FD for ; Mon, 10 Feb 2014 12:17:40 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id c9so11298584qcz.41 for ; Mon, 10 Feb 2014 12:17:40 -0800 (PST) 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; bh=7A3tUzxs/N5KGDNaWRyvEgQ89yz3yig823QLPgluMRk=; b=rXJrwOU3hFyVC5lUkbBjsk5X0o1koILC6ormOCG3FTC/a7oW49iz4ie3IM0f+hwM3U RdEi6SF5fsaLg4NIHWKzzJOXNBixse7ZgCn8xT+lQzgXhXg7Iimyr3p5XTvwhzG/NyJg qr9rudXsNyg1iDYRrpxlFvn9jKalNSlCbvAMChctqcD0h2juzFTytTUpWndLMJhgqvlw 7ZqpTULjWWoQx9AOfekd64ytYOOIQlpKcyqHRbHvBFNHiIE4L4FUUvSaV/alXA7ERVIN kcDF541+1jcpprjo/QPnx3qUwSnfQhV3xtL/+edK5VYTry5w7xlh+6ve407RyR3DJSsU NncA== X-Received: by 10.140.43.3 with SMTP id d3mr47487250qga.70.1392063460568; Mon, 10 Feb 2014 12:17:40 -0800 (PST) Received: from [10.30.20.14] (pool-173-79-6-58.washdc.fios.verizon.net. [173.79.6.58]) by mx.google.com with ESMTPSA id v33sm25328622qgd.10.2014.02.10.12.17.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 12:17:40 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: aside: IPsec tunnels for carrying options/headers end-to-end Date: Mon, 10 Feb 2014 15:17:39 -0500 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.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 20:17:43 -0000 On 2/10/14, Fernando Gont wrote, in part: > On 02/07/2014 09:06 PM, Mark ZZZ Smith wrote: > > End-to-end crypto might the backup plan. > > Depends on what you mean by end-to-end crypto, and in what context. > > SSL/TLS for say, web servers and mailservers, fine. > > IPsec for the general case...mmm.. unlikely. > > Is there any plan for solving the authentication of nodes? The IETF DANE WG. Their initial focus seems to be TLS, but the same approach ought to work fine for IPsec (and was always what I expected to happen, although I thought it would have happened sooner. :-) > Is everyone expected to get/buy a certificate? No. See above. Folks are expected to have DNS, which is already an expectation. To Mark's point at the very top, tunnelling is indeed one method to permit options/headers/new-protocols to be deployed, but it assumes cooperating endpoints who can encapsulate/decapsulate as appropriate. Yours, Ran From fernando@gont.com.ar Mon Feb 10 12:34:44 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0FA71A046A for ; Mon, 10 Feb 2014 12:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rF8zL24hGGfN for ; Mon, 10 Feb 2014 12:34:43 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 32BC01A0410 for ; Mon, 10 Feb 2014 12:34:40 -0800 (PST) Received: from [2001:5c0:1000:a::81f] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WCxYt-0004E8-DK; Mon, 10 Feb 2014 21:34:39 +0100 Message-ID: <52F9363B.3000507@gont.com.ar> Date: Mon, 10 Feb 2014 17:27:39 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: RJ Atkinson , ipv6@ietf.org Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers References: <52F9233A.1080304@gmail.com> <3A917394-1407-485B-BB08-6823D4A60985@gmail.com> In-Reply-To: <3A917394-1407-485B-BB08-6823D4A60985@gmail.com> 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.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 20:34:44 -0000 On 02/10/2014 05:07 PM, RJ Atkinson wrote: > BOTTOM LINE: > > I don't think that draft-gont-6man-ipv6-universal-extension-header > is worth any time investment, because it can't change the deployed > operational behaviour. FWIW, if anything, I care about middle-boxes being able to process the entire IPv6 header chain, and differentiate between transport protocols and ext headers. Among the possible ways to do this are: 1) Ban new ext headers once and for all, xor, 2) Do something like the UEH we specified, xor, 3) Reserve a range for the universal format in RFC 6465. And if we do anything other than 3), possibly also clarify that the section on the universal format in RFC 6465 is to be forgotten -- because quite a few of us got confused with it. While I have my preference, any of the above 3 would work for me. Now, if you ask what are my personal beliefs regarding deployability of Ext Headers in the public Internet, my take would be "Forget it -- It won't work". > If we bother to do anything, we ought to just acknowledge reality > and say that no more IPv6 extension *headers* are allowed. Instead, > options must be used. We also should note that options with hop-by-hop > behaviour likely cannot be deployed reliably across the global public > Internet. That would mean that any "new" NextHeader value would > denote a transport-layer protocol (which I think also would be > very difficult to deploy - I have never seen SCTP on-the-wire). For SCTP/IPv4, the reason for not seeing SCTP is probably NATs. -- Also, neither Windows nor Linux support it AFAICT. While in IPv6 this could be different, I expect firewalls that "only allow outgoing connections" to be pretty common... so one way or another, they situation would not be that different. 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 stig@venaas.com Mon Feb 10 13:16:29 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33A81A05D6 for ; Mon, 10 Feb 2014 13:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tW-da5B7I0Dl for ; Mon, 10 Feb 2014 13:16:27 -0800 (PST) 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 92BD81A0564 for ; Mon, 10 Feb 2014 13:16:26 -0800 (PST) Received: from [IPv6:2001:420:301:1004:9c1c:c7c0:5307:24f8] (unknown [IPv6:2001:420:301:1004:9c1c:c7c0:5307:24f8]) by ufisa.uninett.no (Postfix) with ESMTPSA id 8924F8025; Mon, 10 Feb 2014 22:16:24 +0100 (CET) Message-ID: <52F941A5.6040103@venaas.com> Date: Mon, 10 Feb 2014 13:16:21 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , draft-ietf-6man-multicast-addr-arch-update@tools.ietf.org Subject: Re: comments on draft-ietf-6man-multicast-addr-arch-update-02 References: <52E0570D.4040403@venaas.com> In-Reply-To: <52E0570D.4040403@venaas.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 21:16:29 -0000 Hi, sorry for delay, but let me comment on this now. On 1/22/2014 3:41 PM, Stig Venaas wrote: > Hi > > Thanks for the review. > > I'm sorry I didn't find time to respond to this. Let's see what other > comments we get in the WGLC that is ongoing. I'll then try to address > this and any other comments afterwards. > > Stig > > On 11/13/2013 1:35 PM, 神明é”哉 wrote: >> As promised in the Vancouver meeting, I reviewed the draft. Overall, >> it looks good to me. I have a few minor comments: >> >> - Allowing FFF0::/12 to be considered an embedded RP address seems to >> me a semantics change, not just a clarification (as hinted in the >> introduction), since RFC 3956 clearly states (and also as cited in >> the draft itself): >> >> the encoding and the >> protocol mode used when the two high-order bits in "flgs" are set to >> 11 ("FFF0::/12") is intentionally unspecified until such time that >> the highest-order bit is defined. >> >> So does this mean "such time" has come? I guess there was a >> background discussion that I didn't follow and led to this change, >> so I wouldn't oppose to the update per se. But the rationale isn't >> really clear from the updated text, and I think it should be >> clarified. As part of this update we are trying to treat the flag bits as individual bits. Hence it should still be embedded-RP if the most significant flag bit is set. >> - Aside from the previous point, the updated text is generally quite >> confusing to me: >> >> R = 1 indicates a multicast address that embeds the address of >> the RP. >> P MUST be set to 1, and consequently T MUST be set to 1, according >> to [RFC3306], as this is a special case of >> unicast-prefix based addresses. This implies that for instance >> prefixes >> ff70::/12 and fff0::/12 are embedded RP prefixes, but all >> multicast >> addresses with the R-bit set to 1 MUST be treated as Embedded RP >> addresses. The behavior is unspecified if P or T is not set to >> 1. When the >> R-bit is set, the last 4 bits of the previously reserved field are >> interpreted as embedding the RP interface ID, as specified in >> this memo. We can remove the sentence ", but all multicast addresses with the R-bit set to 1 MUST be treated as Embedded RP addresses." It is a valid statement, but not really needed. >> As explained in the first sentence, for any embedded-RP addresses >> both P and T must be 1. As a logical consequence, an address with P >> or T being 0 cannot be an embedded-RP addresses, right? Yet the >> text states "all multicast addresses with the R-bit set to 1 MUST be >> treated as Embedded RP addresses". Maybe the "behavior is >> unspecified if P or T is not set to 1" part in the subsequent >> sentence tries to address the point, but it's still confusing to me >> - specifically what does "MUST be treated as Embedded RP addresses" >> mean, then? I think some more clarification is necessary here. >> >> - In Section 4.1, I suspect the "NEW" format needs the new "flgs" >> bits: >> >> NEW: >> >> | 8 | 4 | 4 | 8 | 8 | 64 | >> 32 | >> >> +--------+----+----+--------+--------+----------------+----------+ >> |11111111|flgs|scop|reserved| plen | network prefix | >> group ID | >> >> +--------+----+----+--------+--------+----------------+----------+ >> ^^^^ <= should be "flgs" >> >> And, with this change, the following part will become ambiguous: >> >> +-+-+-+-+ >> flgs is a set of 4 flags: |X|Y|P|T| >> +-+-+-+-+ >> >> Since there are now 2 "flgs" fields. The same comment applies to >> the NEW formats shown in Section 4.2. Agree. So maybe should call them flag field 1 and flag field 2 and write ff1 and ff2 in the diagram. >> - Also in the NEW format of Section 4.1, I'm not sure if [ADDRARCH] is >> an appropriate reference, e.g., in: >> >> o P = 0 indicates a multicast address that is not assigned >> based on the network prefix. This indicates a multicast >> address as defined in [ADDRARCH]. >> >> Since there's no such reference in this document. For the OLD text >> it's probably okay as it should be a verbatim copy of the original >> text, but I'm not sure if it should apply to the new text. Yes. I think we should change it to 4291. >> - (A very minor point) Also in the NEW format of Section 4.1, why >> lower-cased letters are now used for the addresses? >> >> If the flag bits are set to 0011, these settings create an SSM >> range of ff3x::/32 (where 'x' is any valid scope value). The >> >> The policy isn't consistent either with the original RFC 3306 or >> with other parts of the draft. A lot of the OLD text has FF, but per recommendation in RFC 5952 we use lower case in all the NEW text. >> - In the NEW format of Section 4.2, this sentence may need to be >> revisited: >> >> In this case, the last 4 >> bits of the previously reserved field are interpreted as embedding >> the RP interface ID, as specified in this memo. >> >> in that what "the previously reserved field" means is not really >> clear as this document now also is revising RFC 3306. To be very >> clear, for example, I'd rephrase it as: >> >> In this case, the last 4 >> bits of the field that were reserved in [RFC3306] are >> interpreted as embedding the RP interface ID, as specified in >> this memo. OK, will try to improve this one. Thanks for the review, Stig >> -- >> JINMEI, Tatuya >> -------------------------------------------------------------------- >> 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 sarikaya2012@gmail.com Mon Feb 10 13:41:09 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9334C1A06FD for ; Mon, 10 Feb 2014 13:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rR5f6dWA9eLW for ; Mon, 10 Feb 2014 13:41:07 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 790821A08AD for <6man@ietf.org>; Mon, 10 Feb 2014 13:41:07 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id s7so3718161lbd.18 for <6man@ietf.org>; Mon, 10 Feb 2014 13:41:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=o1IohR5YKh1Qe2SKUE+/HE+1nSxxBLdNHmXb3DdyxzU=; b=J4wzVQf578YGpFQwOF6zImfjHmS4UHwjg4hRMga1zwyXGqTaBR2K7U53BuV9Dij59W S6WfKQApZOEJzm4fEpc+0gNooVvUjPnPsWH1ZGDuEVCrLoDhsK4IWRyiX0tD2OAb1ote ZZGIhrYAmdSXncQusZPkefC1Z2gG9bTTc7o1GJnd7q5rIJvqLrmSnJibbujlbmvfgb3j ny9d2fnug/0OHYPNrirTxnMbsRrNH40RBMwRZ/ShtaKubfaqdXAcHJhH83CqY3tXRQEC sfDV++h6Aj2QlftFMDrgmrPFOVinEcoTSvLo3ThX153dEBqNqUX3WiXYaooN1Dx8QKVs tXjw== MIME-Version: 1.0 X-Received: by 10.112.137.137 with SMTP id qi9mr3518386lbb.36.1392068466524; Mon, 10 Feb 2014 13:41:06 -0800 (PST) Received: by 10.114.170.193 with HTTP; Mon, 10 Feb 2014 13:41:06 -0800 (PST) In-Reply-To: <20140210213947.14657.20184.idtracker@ietfa.amsl.com> References: <20140210213947.14657.20184.idtracker@ietfa.amsl.com> Date: Mon, 10 Feb 2014 15:41:06 -0600 Message-ID: Subject: Fwd: New Version Notification for draft-sarikaya-6man-next-hop-ra-00.txt From: Behcet Sarikaya To: "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary=089e012287b87346c504f214325f X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 21:41:09 -0000 --089e012287b87346c504f214325f Content-Type: text/plain; charset=ISO-8859-1 Hi all, I submitted this draft, appreciate your comments. Regards, Behcet A new version of I-D, draft-sarikaya-6man-next-hop-ra-00.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Name: draft-sarikaya-6man-next-hop-ra Revision: 00 Title: IPv6 RA Options for Next Hop Routes Document date: 2014-02-10 Group: Individual Submission Pages: 15 URL: http://www.ietf.org/internet-drafts/draft-sarikaya-6man-next-hop-ra-00.txt Status: https://datatracker.ietf.org/doc/draft-sarikaya-6man-next-hop-ra/ Htmlized: http://tools.ietf.org/html/draft-sarikaya-6man-next-hop-ra-00 Abstract: This document proposes new Router Advertisement options for configuring next hop routes on the mobile or fixed nodes. Using these options, an operator can easily configure nodes with multiple interfaces (or otherwise multi-homed) to enable them to select the routes to a destination. Each option is defined together with definitions of host and router behaviors. This document also proposes the router advertisement extensions for source address dependent routing. 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 --089e012287b87346c504f214325f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

I submitted this draft= , appreciate your comments.

Regards,

Behcet



A new version of I-D, draft-sarikaya-6man-next-hop-ra-00.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Name: =A0 =A0 =A0 =A0 =A0 draft-sarikaya-6man-next-hop-ra
Revision: =A0 =A0 =A0 00
Title: =A0 =A0 =A0 =A0 =A0IPv6 RA Options for Next Hop Routes
Document date: =A02014-02-10
Group: =A0 =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0 =A0 =A015
URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.o= rg/internet-drafts/draft-sarikaya-6man-next-hop-ra-00.txt
Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org/d= oc/draft-sarikaya-6man-next-hop-ra/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-sar= ikaya-6man-next-hop-ra-00


Abstract:
=A0 =A0This document proposes new Router Advertisement options for
=A0 =A0configuring next hop routes on the mobile or fixed nodes. =A0Using =A0 =A0these options, an operator can easily configure nodes with multiple<= br> =A0 =A0interfaces (or otherwise multi-homed) to enable them to select the =A0 =A0routes to a destination. =A0Each option is defined together with
=A0 =A0definitions of host and router behaviors. =A0This document also
=A0 =A0proposes the router advertisement extensions for source address
=A0 =A0dependent routing.




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

The IETF Secretariat


--089e012287b87346c504f214325f-- From brian@innovationslab.net Mon Feb 10 15:16:02 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956841A061A for ; Mon, 10 Feb 2014 15:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpsbYjmazBX7 for ; Mon, 10 Feb 2014 15:16:00 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id B17301A066E for ; Mon, 10 Feb 2014 15:16:00 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id C32E6880D1 for ; Mon, 10 Feb 2014 15:16:00 -0800 (PST) Received: from Littlejohn.local (c-76-21-129-88.hsd1.md.comcast.net [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 603E51368024 for ; Mon, 10 Feb 2014 15:16:00 -0800 (PST) Message-ID: <52F95DAE.6080200@innovationslab.net> Date: Mon, 10 Feb 2014 18:15:58 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Comments on draft-ietf-6man-multicast-addr-arch-update-02 References: <52F91975.9060704@venaas.com> In-Reply-To: <52F91975.9060704@venaas.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="X4BJlpAJx8qG4XDVjBVWR8skruuhlWOql" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 23:16:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --X4BJlpAJx8qG4XDVjBVWR8skruuhlWOql Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Stig, On 2/10/14 1:24 PM, Stig Venaas wrote: > Hi Jouni >=20 > On 2/10/2014 1:23 AM, Jouni Korhonen wrote: >> Sorry being a bit late but I had a read of this document. >> >> ** Some nits: >> >> s/[ADDRARCH]/[RFC4291] >> >> ** While I agree this document is needed there is a general procedural= >> issue I have. This I-D patches three other RFCs, which over the time >> may become an issue. I would rather see each document having their >> own bis and RFC4291 update being the master on all of these updates. I= >> recon it might be awfully late for this, though. >=20 > I agree. I'm not sure what is the right thing to do here, I've also bee= n > wondering if what you say would be better. I've been asking this > question several time, but I haven't really got much feedback. >=20 > I wonder if it might be worth checking with the IESG or others to see > what the best way is. It would be a big task updating those documents > though. One way forward could be to publish this document soon, and the= n > work on bis versions of those documents that may also include other > improvements. >=20 I will point out that I suggested doing errata or -bis documents several times. I don't those updates would be that involved. There really is only a need to clarify the definition of the flgs and possibly highlighting the relationship between the specs. Regards, Brian --X4BJlpAJx8qG4XDVjBVWR8skruuhlWOql Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS+V2vAAoJEBOZRqCi7goqp20H/iTsvH98iFBghg96740n+S6Z CC28xrhh4kmw7ZieRQdsQv/TBK9uXElCJNvF7yaUrIKQt9oZazqreipMIan4N/zT iM4B+pVxjca9WP22LuhTMvi2SU/fQaREZjJsVw0d8RFQHsZuMkVibmO5JglvOW99 tVdjj7CpOKApq2rvotJJLtNLCP0fid3ARxKcEJ5PsSeEVfMGS+6gxvpwzcj+HK3y 9lGZN+pw1IZatFBplY7U+BZgxYO9hdqofSDkivpvVdZMcsL5WVQP+UwxDoTRNRVR 0XR3kr6bX4MXge4huh9ugADQwEZs6S5HBdr3OC0vSU9KsHryrClfT0JBO4RTQMo= =DWQp -----END PGP SIGNATURE----- --X4BJlpAJx8qG4XDVjBVWR8skruuhlWOql-- From wwwrun@rfc-editor.org Mon Feb 10 20:26:21 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9401A08C6; Mon, 10 Feb 2014 20:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gung6XQUzKou; Mon, 10 Feb 2014 20:26:19 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id E26AB1A08CC; Mon, 10 Feb 2014 20:26:16 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id AC9767FC3AA; Mon, 10 Feb 2014 20:26:16 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 7136 on Significance of IPv6 Interface Identifiers From: rfc-editor@rfc-editor.org Message-Id: <20140211042616.AC9767FC3AA@rfc-editor.org> Date: Mon, 10 Feb 2014 20:26:16 -0800 (PST) Cc: drafts-update-ref@iana.org, ipv6@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 04:26:22 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7136 Title: Significance of IPv6 Interface Identifiers Author: B. Carpenter, S. Jiang Status: Standards Track Stream: IETF Date: February 2014 Mailbox: brian.e.carpenter@gmail.com, jiangsheng@huawei.com Pages: 10 Characters: 23172 Updates: RFC 4291 I-D Tag: draft-ietf-6man-ug-06.txt URL: http://www.rfc-editor.org/rfc/rfc7136.txt 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 meaning and that the entire 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 the process of deriving interface identifiers from an IEEE link-layer address, and it updates RFC 4291 accordingly. 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 v6ops@globis.net Tue Feb 11 00:56:04 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3F01A090E for ; Tue, 11 Feb 2014 00:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3nLy2qRdyyY for ; Tue, 11 Feb 2014 00:56:02 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4730D1A0906 for <6man@ietf.org>; Tue, 11 Feb 2014 00:56:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 6AC10870073; Tue, 11 Feb 2014 09:55:59 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5feQoaWBXEjC; Tue, 11 Feb 2014 09:55:59 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 40C2D870070; Tue, 11 Feb 2014 09:55:59 +0100 (CET) Message-ID: <52F9E59F.8000408@globis.net> Date: Tue, 11 Feb 2014 09:55:59 +0100 From: Ray Hunter User-Agent: Postbox 3.0.9 (Macintosh/20140129) MIME-Version: 1.0 To: "C. M. Heard" Subject: Re: Re: A problem with RFC 6465's Uniform Format for Extension Headers References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <52F13D1D.9050800@gont.com.ar> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Fernando Gont , 6MAN <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 08:56:04 -0000 C. M. Heard wrote: > On Tue, 4 Feb 2014, Fernando Gont wrote: >> On 02/04/2014 11:20 AM, Jen Linkova wrote: >>> Somehow that proposed Universal Extension Header looks exactly like an >>> Options Extension Header to me. >>> Am I missing something? I'm trying to use my imagination but couldn't >>> see any possible scenario when UEH would work and Options header would >>> not. > > In an offline discussion with Fernando before his draft was submitted > I made the following comments: > > | This seems technically sound and is probably what RFC 6564 should > | have said in the first place. However, playing devil's advocate, > | let me ask if there is a reason why the Destination Options header > | would not serve the same purpose as the universal extension header > | [...], so long as that header is allowed to appear multiple times at > | any position in between the Hop-By-Hop options header (if present) > | and the Fragment Header or the upper layer header. > > In the absence of a strong argument to the contrary, it seems to me > that the existing Destination Options header can be used to do > exactly the same thing as the proposed UEH. In other words, I agree > with Jen's comments. > > Fernando went on to write: >> Not sure what you mean. >> >> But please let me provide an example: >> >> Let's say that, tomorrow, the IETF standardizes the GTP (Google >> Transport Protocol :-)), and it is assigned the Next Header value 0xFF >> (I'm assuming this one is not currently assigned, bbut I'm not checking >> the IANA registry right now). >> >> Say a middle-box receives a packet that simply encapsulates GTP in IPv6, >> and that middlebox does not yet support GTP. If the middle-box tries to >> interpret the GTP header as in RFC6465, it will certainly fail. >> >> The reason? -- RFC 6465 implicitly assumes that every new Next Header >> will employ the RFC6465 format. This may be sensible for new *extension >> headers*, but certainly not for new transport protocols. >> >> And since transport protocols and extension headers share the same >> namespace (see RFC7045), this is a problem. > > All this is true. The implication is that the middlebox must stop > parsing the header chain when it encounters an unknown Next Header. > > In more detail, I see the three cases: > > 1.) The middlebox encounters an ESP Next Header, signalling that an > encrypted payload follows. In that case it stops parsing the > header chain and applies its policy for encrypted payloads. > > 2.) The middlebox encounters a Next Header corresponding to a known > transport protocol. In that case it may perform filtering > actions specific to that transport protocol (and of course may > continue parsing into the transport header in order to do so). > > 3.) The middlebox encounters an unknown Next Header value. In that > case it stops parsing the header chain and applies its policy > for packets with unknown Next Header values. In order to comply > with RFC 7045, it MUST be possible to configure the policy to > allow such packets, but the default MAY be to drop them. A > high-quality implementation would allow the policy to be > configured individually for each unknown Next Header value. > > I agree that there are use cases where it is important for a middlebox > to clearly distinguish between an unknown extension header and an > unknown transport protocol. One is RA Guard: see I agree with the above analysis for the current situation. I think this draft is worth pursuing, to see if the decision tree can be extended to differentiate between an unknown IPv6 header, and an unknown upper layer header. Some in the IETF seem to think that end to end encrypted tunnels are "the solution". I think this just moves the battlefield: end users will insist that encrypted tunnels are terminated on a security device, which then inspects the packet, potentially resulting in less security rather than more as certificates then have to be installed on the middleware box. The middleware box also then becomes a DOS target itself, as it has to perform significant amounts of processing. End users and major enterprises demand that they can look inside packets at near wire speed and filter traffic traversing their AS boundary in a granular manner according to a security policy that they can tweak themselves. IMHO The IETF should accept that starting point as a basic requirement for protocol development, and facilitate simple parsing and granular filtering at high speed. Anything not complying with this basic requirement is unlikely to be deployed. > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard-implementation/ > >> What we did in our I-D is specify a new Extension Header, that is >> assigned a Next-Header value. Let us assume that our proposal moves >> forward, and the UEH is assigned the next header value 0xfe. >> >> If a middle-box supports UEH but does not support our (fictitious) GTP >> protocol above, then, if a GTP packet encapsulated in IPv6 is received, >> GTP will be identified as an "upper-layer protocol", rather than as UEH >> (since the Next Header value will be 0xff, rather than UEH's 0xfe). >> >> Clearly, another way to go is to reserve part of the IANA's Next Header >> namespace for RFC6465, and leave the rest for transport protocols -- as >> suggested by Hagen. >> >> What's clear is that the only way in which RFC6465 can possibly work is >> if the middle-box has some a-priori knowledge that what is being >> encapsulated follows RFC6465 -- whether as a result of a reserved range >> (as originally proposed by Hagen) or by specifying a single UEH, and >> then encoding all possible future "extension headers" as subtypes of UEH. > > A third possibility would be to go a step further than RFC 6564 and > ban new extension headers outright, insisting that a Destination > Option be used instead. RFC 6564 already says that a new extension > header may be defined only as a last resort, requiring proof that a > Destination Option will not work. > > Can anyone offer up a scenario where a Destination Option will not > work? > > Mike Heard > -- Regards, RayH From jinmei.tatuya@gmail.com Tue Feb 11 11:55:33 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90DF1A0722 for ; Tue, 11 Feb 2014 11:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.078 X-Spam-Level: X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ye9c-XSXyo4l for ; Tue, 11 Feb 2014 11:55:31 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id D852F1A072F for ; Tue, 11 Feb 2014 11:55:30 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id hn9so5204857wib.6 for ; Tue, 11 Feb 2014 11:55:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qnZmLpFmKcjyF3bYLiYjkW0btSok4poUjw0uaOteWPg=; b=MWBJsy8CVwq2F0qJqXuMK7oXPkZOsBmJlaZxXuUrzXMn3lDkaYv5zKhM0H/d7P05Dz Z5kNMhgT/q5C8kMYX979m29NRl/aI3vnmf3gY9MGMKa2GD56p09GVtza7hnXNjySixXa 3O3cvycDWqJqJD/+MCfkCsEo91B/78Y0Z2LA7W58/BJAYlRe07zPdW/lqsMhRlIGa+gP PqT2MnOMRQ93TT3nw33uAD27E6/Z+VoWGxrzlDGt/ERJBId1ZtcACPOKyJLRXH3qVOah /Dn1FbU/Ug+h2INr1K3+2w4O5Lym72jWmxhc2BqfwsvIg92kVyGIdt8KWAtICTN9cORL mmmw== MIME-Version: 1.0 X-Received: by 10.195.13.17 with SMTP id eu17mr27828806wjd.24.1392148529762; Tue, 11 Feb 2014 11:55:29 -0800 (PST) Sender: jinmei.tatuya@gmail.com Received: by 10.194.120.167 with HTTP; Tue, 11 Feb 2014 11:55:29 -0800 (PST) In-Reply-To: <52F941A5.6040103@venaas.com> References: <52E0570D.4040403@venaas.com> <52F941A5.6040103@venaas.com> Date: Tue, 11 Feb 2014 11:55:29 -0800 X-Google-Sender-Auth: BfaNs7p-gfefvncVf21HkDzYWfA Message-ID: Subject: Re: comments on draft-ietf-6man-multicast-addr-arch-update-02 From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Stig Venaas Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-6man-multicast-addr-arch-update@tools.ietf.org, IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 19:55:33 -0000 At Mon, 10 Feb 2014 13:16:21 -0800, Stig Venaas wrote: > >> - Allowing FFF0::/12 to be considered an embedded RP address seems to > >> me a semantics change, not just a clarification (as hinted in the > >> introduction), since RFC 3956 clearly states (and also as cited in > >> the draft itself): [...] > >> So does this mean "such time" has come? I guess there was a > >> background discussion that I didn't follow and led to this change, > >> so I wouldn't oppose to the update per se. But the rationale isn't > >> really clear from the updated text, and I think it should be > >> clarified. > > As part of this update we are trying to treat the flag bits as > individual bits. Hence it should still be embedded-RP if the most > significant flag bit is set. I guess I was not clear/accurate enough. My point is that (at least technically) Section 3.1 is not just a "clarification" as this draft claims in Section 1: [...] The document provides also some clarifications related to the use of these flag bits (Section 3.1). since as a result of this the definition of embedded-RP addresses is changed (extended). Maybe revising the last sentence of Section 1 addresses my concern: This document updates [RFC3956], [RFC3306], and [RFC4291]. Some of the updates are logical consequences of the clarification on the flag bits. > >> - Aside from the previous point, the updated text is generally quite > >> confusing to me: > >> > >> R = 1 indicates a multicast address that embeds the address of > >> the RP. > >> P MUST be set to 1, and consequently T MUST be set to 1, according > >> to [RFC3306], as this is a special case of > >> unicast-prefix based addresses. This implies that for instance > >> prefixes > >> ff70::/12 and fff0::/12 are embedded RP prefixes, but all > >> multicast > >> addresses with the R-bit set to 1 MUST be treated as Embedded RP > >> addresses. The behavior is unspecified if P or T is not set to > >> 1. When the > >> R-bit is set, the last 4 bits of the previously reserved field are > >> interpreted as embedding the RP interface ID, as specified in > >> this memo. > > We can remove the sentence ", but all multicast addresses with the > R-bit set to 1 MUST be treated as Embedded RP addresses." It is a valid > statement, but not really needed. I think that works for me, although it looks a bit awkward that we can simply remove a statement containing a "MUST" while believing it's not a semantics change. > >> - (A very minor point) Also in the NEW format of Section 4.1, why > >> lower-cased letters are now used for the addresses? > >> > >> If the flag bits are set to 0011, these settings create an SSM > >> range of ff3x::/32 (where 'x' is any valid scope value). The > >> > >> The policy isn't consistent either with the original RFC 3306 or > >> with other parts of the draft. > > A lot of the OLD text has FF, but per recommendation in RFC 5952 we > use lower case in all the NEW text. Ah, okay. Maybe it's a distraction, but I'd consider adding a "TERMINOLOGY" section or something, where we clarify the point (i.e., the draft generally follows RFC 5952 to represent IPv6 addresses except in citation of already published documents). But I'd leave it to you. -- JINMEI, Tatuya From kawamucho@mesh.ad.jp Tue Feb 11 20:58:06 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28B81A0841 for ; Tue, 11 Feb 2014 20:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.692 X-Spam-Level: X-Spam-Status: No, score=-1.692 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzE094DvVhJy for ; Tue, 11 Feb 2014 20:58:04 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by ietfa.amsl.com (Postfix) with ESMTP id F03D91A0840 for ; Tue, 11 Feb 2014 20:58:03 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.197]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id s1C4vbM0018870; Wed, 12 Feb 2014 13:57:37 +0900 (JST) Received: from mailsv4.nec.co.jp (imss62.nec.co.jp [10.7.69.157]) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) with ESMTP id s1C4va309535; Wed, 12 Feb 2014 13:57:36 +0900 (JST) Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id s1C4vaSI007571; Wed, 12 Feb 2014 13:57:36 +0900 (JST) Received: from mail.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id s1C4va5S000519; Wed, 12 Feb 2014 13:57:36 +0900 Received: from [127.0.0.1] ([10.84.99.49]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/10031711) with ESMTP id s1C4vaHL015432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Feb 2014 13:57:36 +0900 Message-ID: <52FAFF44.2080307@mesh.ad.jp> Date: Wed, 12 Feb 2014 13:57:40 +0900 From: Seiichi Kawamura User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: RFC Errata System , kawashimam@vx.jp.nec.com, brian@innovationslab.net, ted.lemon@nominum.com, bob.hinden@gmail.com, otroan@employees.org Subject: Re: [Technical Errata Reported] RFC5952 (3884) References: <20140206100013.9F25D7FC158@rfc-editor.org> In-Reply-To: <20140206100013.9F25D7FC158@rfc-editor.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 04:58:06 -0000 Hi Thanks for your comments. RFC5952 updates RFC4291. In RFC4291 section 2.2 states The use of "::" indicates one or more groups of 16 bits of zeros. so in the case you raise, > You would think this should be obvious, but I have seen actual discussions that 2001:db8:1:1::1:1:1:1 is correct syntax. Explicitly forbidding this form does no harm and stops all discussions in this direction. those people must not have read RFC4291. RFC5952 section 4. first paragraph specifically states "The recommendation in this document is one that complies fully with [RFC4291]" It took me a while to figure out what you were trying to point out to with your revised text, so the best way I think is to put a pointer to RFC4291, which we've already done. So I don't really see much of a need to revise for this. Regards, Seiichi (2014/02/06 19:00), RFC Errata System wrote: > The following errata report has been submitted for RFC5952, > "A Recommendation for IPv6 Address Text Representation". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5952&eid=3884 > > -------------------------------------- > Type: Technical > Reported by: Richard Hartmann > > Section: 4.2.2. > > Original Text > ------------- > 4.2.2. Handling One 16-Bit 0 Field > > The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field. > For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but > 2001:db8::1:1:1:1:1 is not correct. > > Corrected Text > -------------- > 4.2.2. Incorrect use of "::" > > The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field. > For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but > 2001:db8::1:1:1:1:1 is not correct. > > The symbol "::" MUST NOT be used just so. For example, the > representation 2001:db8:1:1:1:1:1:1 is correct, but > 2001:db8:1:1::1:1:1:1 is not correct. > > Notes > ----- > You would think this should be obvious, but I have seen actual discussions that 2001:db8:1:1::1:1:1:1 is correct syntax. Explicitly forbidding this form does no harm and stops all discussions in this direction. > > Thanks for your work. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5952 (draft-ietf-6man-text-addr-representation-07) > -------------------------------------- > Title : A Recommendation for IPv6 Address Text Representation > Publication Date : August 2010 > Author(s) : S. Kawamura, M. Kawashima > Category : PROPOSED STANDARD > Source : IPv6 Maintenance > Area : Internet > Stream : IETF > Verifying Party : IESG > From heard@pobox.com Tue Feb 11 22:42:10 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49C21A0815 for ; Tue, 11 Feb 2014 22:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmrV-l9z-H1J for ; Tue, 11 Feb 2014 22:42:08 -0800 (PST) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5311A07FF for <6man@ietf.org>; Tue, 11 Feb 2014 22:42:07 -0800 (PST) Received: (qmail 1615 invoked from network); 11 Feb 2014 22:42:05 -0800 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 11 Feb 2014 22:42:05 -0800 Date: Tue, 11 Feb 2014 22:42:05 -0800 (PST) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: 6MAN <6man@ietf.org> Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers In-Reply-To: <52F804B3.5040803@gmail.com> Message-ID: References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <52F13D1D.9050800@gont.com.ar> <52F804B3.5040803@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 06:42:10 -0000 On Mon, 10 Feb 2014, Brian E Carpenter wrote: > On 10/02/2014 08:35, C. M. Heard wrote: > ... > > In the absence of a strong argument to the contrary, it seems to me > > that the existing Destination Options header can be used to do > > exactly the same thing as the proposed UEH. In other words, I agree > > with Jen's comments. > > I think we should carry out a thought experiment: consider each > of the existing extension headers, listed in RFC 7045 and at > http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header > and see which of them could or could not be encoded as > destination options. > > For some of them the answer is obvious, of course. But the others would > give us an idea whether the 'option' option has enough flexibility. That is a good idea and I am going to take a stab at it. In looking over the references for the existing extension headers listed in RFC 7045 and in the above-referenced IANA registry it appears to me that the order in which headers other than experimental use headers 253 and 254 should appear is as follows (this is an update of RFC 2460 Section 4.1): IPv6 header Hop-by-Hop Options header Destination Options header (note 1) Routing header Shim6 header Fragment header Authentication header (note 2) Encapsulating Security Payload header (note 2) Destination Options header (note 3) Mobility Header or Host Identity header (note 4) upper-layer header 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. note 2: additional recommendations regarding the relative order of the Authentication and Encapsulating Security Payload headers are given in [RFC-2406]. note 3: for options to be processed only by the final destination of the packet. note 4: at present, these headers are required to contain No Next Header, so an upper-layer header will not follow these headers. To see if the 'option' option has enough flexibility, let's consider each header in turn to see whether it could reasonably be replaced by one of the following: - hop-by-hop option - destination option - upper-layer header or (for the three kinds of headers listed above) how the rules for usage would be changed by a ban on new IPv6 extension headers. This is a bit more general question than the one posed by Brian Carpenter, but I think it's the right way to go when determining whether a ban on new extension headers would limit flexibility. Hop-by-Hop Options header: this header is needed to clearly distinguish hop-by-hop and destination options. It is (and always has been) the only means to include optional IPv6 data with hop-by-hop semantics. A ban on new extension headers would not change this. Destination Options header: this header is needed to clearly distinguish hop-by-hop and destination options. Using a destination option in place of an extension header could require that this header be allowed to appear more than twice in the IPv6 header chain or introduce constraints regarding the order in which destination options would be allowed to appear. Routing header: IPv4 provides an existence proof that this extension header could be replaced by a destination option. Such an option would be carried in a Destination Options header immediately following the Hop-by-Hop Options header if present or the IPv6 header otherwise. Shim6 header: as far as I can tell, the situation is exactly the same as for the Routing header. In cases where an IPv6 packet contains only Shim6 control information and no ULP data, the Next Header value of the containing Destination Options header would be No Next Header. Fragment header: it is my assessment that while it might be possible to make this into a destination option, that would add a good deal of awkwardness to an already awkward and error-prone function. On that basis I would say that using an extension header was justified in this case. Authentication header: it certainly would be possible to encode the equivalent information into a destination option, but because of the fact that the authentication is done prior to fragmentation or after reassembly it would be necessary to allow a separate Destination Option header to appear where the Authentication header now appears. However, since AH is used for both IPv4 and IPv6, that would not have been a good engineering choice, and I would say that using an extension header was justified in this case. Encapsulating Security Payload header: as noted in RFC 4303, "in the IPv6 context, ESP is viewed as an end-to-end payload," and we treat is as such when determining where an IPv6 header chain ends. It would not make sense to replace it with a destination option, but if the concept of an extension header did not exist, we would just treat it as an upper-layer header that contains tunneled encrypted data. Mobility Header and Host Identity header: unless I am missing something, these are used to carry control messages and always have a Next Header value of No Next Header, allowing some future flexibility to include piggybacked data in a standard way. As far as I am able to tell, exactly the same goal could be achieved by defining these as upper-layer protocol headers. Experimental Use headers (protocol numbers 253 and 254): since these could be either extension headers or transport protocols per then whim of the experimenter, there is no defined function to evaluate. However, if we go with the 'option' option, these would turn into experimental upper-layer headers, and the experimental-use options would be used for experiments that wanted to "sandwich" optional data into an IPv6 header. Thoughts? Mike Heard From richih.mailinglist@gmail.com Tue Feb 11 22:52:11 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262F41A0864 for ; Tue, 11 Feb 2014 22:52:11 -0800 (PST) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIbyfFSamVL8 for ; Tue, 11 Feb 2014 22:52:09 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9591A0865 for ; Tue, 11 Feb 2014 22:52:09 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hi5so6238812wib.9 for ; Tue, 11 Feb 2014 22:52:08 -0800 (PST) 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=g8oQEYUM8MC0nVcLZGmAlR+GJ8Qqzy2aONRZDSz+iKg=; b=gc9pOqOjKGU6m2VOCfzk8j59uPn6K6KvvJ29D3T1Dd9KCWxVCB3XQVsGhD4/DKrH7X zjS/TLsr2tlQHPdATnAq/E/oTx2w0Csf42ImV0wWM3F4xfdMbTBr0/Oc+aXzQpowgoBq Nb/D8mSq38WGu+n5gLZ3J2b0VjJ8IQX/w9V/WM2Z41adwUM9h374ZHHb2AuAAo4urnSQ mXu0D74zZd05Yewk3bX0hkKGowzWqHACbrOmKyjQMIHtEnWfbrKGt1DeJHersQ2LhVqO A0K4iwkgTjlt+Zjb2vTxLc7ka8FoCXq62mHHvdaKBTW8ClZT/gABiZnhmfV9Doki6bkY ZYfw== MIME-Version: 1.0 X-Received: by 10.180.13.5 with SMTP id d5mr834430wic.54.1392187928027; Tue, 11 Feb 2014 22:52:08 -0800 (PST) Received: by 10.194.89.106 with HTTP; Tue, 11 Feb 2014 22:52:07 -0800 (PST) Received: by 10.194.89.106 with HTTP; Tue, 11 Feb 2014 22:52:07 -0800 (PST) In-Reply-To: <52FAFF44.2080307@mesh.ad.jp> References: <20140206100013.9F25D7FC158@rfc-editor.org> <52FAFF44.2080307@mesh.ad.jp> Date: Wed, 12 Feb 2014 07:52:07 +0100 Message-ID: Subject: Re: [Technical Errata Reported] RFC5952 (3884) From: Richard Hartmann To: Seiichi Kawamura Content-Type: multipart/alternative; boundary=001a11c23fbae9479804f230027f Cc: brian@innovationslab.net, ipv6@ietf.org, Bob Hinden , ted.lemon@nominum.com, rfc-editor@rfc-editor.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 06:52:11 -0000 --001a11c23fbae9479804f230027f Content-Type: text/plain; charset=UTF-8 Hi Seiichi, You are correct; sorry for not seeing this myself.. Thanks, Richard Sent by mobile; excuse my brevity. --001a11c23fbae9479804f230027f Content-Type: text/html; charset=UTF-8

Hi Seiichi,

You are correct; sorry for not seeing this myself..

Thanks,
Richard

Sent by mobile; excuse my brevity.

--001a11c23fbae9479804f230027f-- From markzzzsmith@yahoo.com.au Wed Feb 12 00:28:48 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7512F1A0878 for ; Wed, 12 Feb 2014 00:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-u92PPlb4II for ; Wed, 12 Feb 2014 00:28:46 -0800 (PST) Received: from nm33-vm2.bullet.mail.bf1.yahoo.com (nm33-vm2.bullet.mail.bf1.yahoo.com [72.30.239.202]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0C81A0869 for <6man@ietf.org>; Wed, 12 Feb 2014 00:28:46 -0800 (PST) Received: from [98.139.212.153] by nm33.bullet.mail.bf1.yahoo.com with NNFMP; 12 Feb 2014 08:28:45 -0000 Received: from [98.139.212.245] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 12 Feb 2014 08:28:45 -0000 Received: from [127.0.0.1] by omp1054.mail.bf1.yahoo.com with NNFMP; 12 Feb 2014 08:28:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 94178.67689.bm@omp1054.mail.bf1.yahoo.com Received: (qmail 35871 invoked by uid 60001); 12 Feb 2014 08:28:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1392193724; bh=emFsCpbLFII9/f4rPQCDjFeAS5c2U9SWDYuk3TYFTYU=; 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=eCgCO24gMNirjWRs07XakIHnAEAw+7WD3iq7cAll59F1ZVLSwppjbAITd4RdMYntMIctNjg7J9m6QwC//K9eNgz/3RqK8kY4sT0Qkalh1CZGpbBrt9OMmEvpm2ELF2cZnPw79KTE54OytlRZRpPaZlkO+jLvqQOw4x+Hf71Ftrk= 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=ssy1/WQGYhcOo2Sjihi3gTFY1hg5MEESFlRGkdGaT1/Gl21ov0Yyh4MeZrvWXHFh7JURjzOQcGN4FBVlmCJO7QV81yOGtWELb0lvYXyUaiYhMbVZIoNlJADV/VB0OdGb4ADJfNAoXoy6tCgu+LF9dBwFehp0qZDOVTbs781GWbM=; X-YMail-OSG: bGRsahQVM1lafOsb0v07D88XsusqiKPMwANy19j1elxV5rT wxuL3A.Re3npC6a0UeYF1dNCc3a6ItHVC9VXjBVup.8W6cFxLdihYtZKZS4m JLoqSuOjyqRLfsVyVSJaVXR2Z5soX6yn8pTC_Y118QXNOdbT5xoDpJ1U9wf8 h9Jk.VrZ0IcemkWPhf7e7njN9pzVs2SjlsVjBFjWZ3f6r12j0vL0ePSZb.7G xZa5cIpjO777HfWTMqWdfRcj4_jaXnmdNlfxCbb4YpIsNwd5CoRZRpZ.ldrT clK1R2JiKPLRdTWweOOyYD0wh68KhS4nwZ3He1V42ePQVnOzJT6cEsNhC4xM u8SmJAaFWxM7tcQJQnUDODbYLe0zp1k37dXP3I0JkzoVgQ_EIMgmL9O4dRA9 QFsCq3GiNEqZa_FrtqxHgjUqEY3nFY52bj0qL_y8Pbr9QmqFHC8wH1dIhEit ZTNiOrY7ILxIcgQlh0Aas3rbmPMUENoMOZpTzu6XA_kuh1reDP2avEOMmYaU f0h.77G4APGQHyseClPEph5cN0QCPpJPvQJZvzoxc6BlM6QG.0LyZZNKKLZ. KAQ3C1IaTyXROzDB_JzBA1j8- Received: from [49.183.54.168] by web162201.mail.bf1.yahoo.com via HTTP; Wed, 12 Feb 2014 00:28:44 PST X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBGZXJuYW5kbyBHb250IDxmZXJuYW5kb0Bnb250LmNvbS5hcj4KPiBUbzogTWFyayBaWlogU21pdGggPG1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU.OyBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20.OyBPbGUgVHJvYW4gPG90cm9hbkBlbXBsb3llZXMub3JnPgo.IENjOiBUaG9tYXMgTmFydGVuIDxuYXJ0ZW5AdXMuaWJtLmNvbT47IEMuIE0uIEhlYXJkIDxoZWFyZEBwb2JveC5jb20.OyBUaW0gQ2hvd24gPHRqY0BlY3MBMAEBAQE- X-Mailer: YahooMailWebService/0.8.176.634 References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <52F1B8CE.4070803@ericsson.com> <52F1BD1F.2080007@si6networks.com> <52F383A0.7030002@si6networks.com> <52F44A73.3000609@si6networks.com> <86BA587E-A7F8-47B9-AC74-98D3DB9A7E46@employees.org> <52F4DDC7.8070606@si6networks.com> <1391817989.71306.YahooMailNeo@web162204.mail.bf1.yahoo.com> <52F927E0.5080706@gont.com.ar> Message-ID: <1392193724.5329.YahooMailNeo@web162201.mail.bf1.yahoo.com> Date: Wed, 12 Feb 2014 00:28:44 -0800 (PST) From: Mark ZZZ Smith Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers To: Fernando Gont , Fernando Gont , Ole Troan In-Reply-To: <52F927E0.5080706@gont.com.ar> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Thomas Narten , "C. M. Heard" , Tim Chown , "6man@ietf.org" <6man@ietf.org>, Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 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, 12 Feb 2014 08:28:48 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Fernando Gont =0A> To: Mark ZZZ Smith ; Fernando G= ont ; Ole Troan =0A> Cc: Thoma= s Narten ; C. M. Heard ; Tim Chown ; "6man@ietf.org" <6man@ietf.org>; Suresh Krishnan =0A> Sent: Tuesday, 11 February 2014 6:26 AM=0A> Sub= ject: Re: A problem with RFC 6465's Uniform Format for Extension Headers=0A= > =0A> On 02/07/2014 09:06 PM, Mark ZZZ Smith wrote:=0A>>> =0A>>>=A0 If, sa= y, tomorrow you come up with this shiny cool new Dst =0A>>>=A0 Opt-based ex= tension for clients, then, from starters, you would =0A>>>=A0 have to think= of a back-up plan, because in more than 40% cases =0A>>>=A0 your packets w= ould get dropped just because of that extension. -- =0A>>>=A0 that's where = we are right now.=0A>>> =0A>> =0A>>=A0 End-to-end crypto might the backup p= lan.=0A> =0A> Depends on what you mean by end-to-end crypto, and in what co= ntext.=0A> =0A> SSL/TLS for say, web servers and mailservers, fine.=0A> =0A= > IPsec for the general case...mmm.. unlikely.=0A> =0A> Is there any plan f= or solving the authentication of nodes? Is everyone=0A> expected to get/buy= a certificate?=0A>=A0=0A=0AAny or all of them. In the latter case, BTNS mo= de of IPsec (RFC5386) would probably be better than NSA can have everything= (tm) IP because it shrinks their window to be a MITM.=0A=0A=0A> =0A> =0A>>= =A0 I think it might be worth remembering that as per the IETF88 Plenary,= =0A>>=A0 end-to-end encryption is the general direction, and that middle bo= xes=0A>>=A0 less effective/in-effective because of it. So putting a lot of = time=0A>>=A0 and effort into facilitating them might be wasted effort.=0A> = =0A> It's a 1-page to 5-page document (and that's including bolierplates).= =0A>=A0=0A=0AI'm not saying to no do it, just that if e.g., somebody like G= oogle, Apple or Microsoft roll out an update that enables crypto on a very = popular service (similar to how within days, millions of iPhones and iPads = used MPTCP for Siri), the traffic that these middleboxes are inspecting mig= ht "go dark" or become hidden "overnight". If there is a lot of effort invo= lved, it would be wasted if that sort of event happened.=0A=0A> =0A> =0A>>= =A0 I also think multipathing, to take advantage of smartphone/tablet's=0A>= >=A0 multi-homing to the network will also mean middle boxes become less=0A= >>=A0 effective/in-effective. IOS 7 is already using MPTCP for Siri for=0A>= >=A0 example+.=0A> =0A> This is a comment from the URL you posted:=0A> =0A>= >=A0 Yes, it works! Thanks Kristian.=0A>>=A0 However here in Italy 3G carri= ers filter out TCP options.. so SIRI gives=0A>>=A0 up and stops trying to u= se mptcp in the long run.=0A>=A0=0A=0A"Encapsulation of TCP and other Trans= port Protocols over UDP"=0Ahttp://tools.ietf.org/html/draft-cheshire-tcp-ov= er-udp-00=0A=0A=0A"In fact, TCP options are expected to work=0Amore reliabl= y with TCP-over-UDP, because middleboxes will be less able to easily interf= ere with such options, modifying them, stripping them, or dropping packets = containing TCP options, as they often dotoday with native TCP = packets. In particular, Multipath TCP-over-UDP=0Ais expected to wor= k more reliably than native Multipath TCP [RFC6824], because middleboxes th= at interfere with use of those TCP options will be less able to do that whe= n the packets are encapsulated inside UDP."=0A=0A;-)=0A=0A=0A> =0A> Cheers,= =0A> -- =0A> Fernando Gont=0A> e-mail: fernando@gont.com.ar || fgont@si6net= works.com=0A> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076= FFF1=0A> From wwwrun@rfc-editor.org Wed Feb 12 06:30:02 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9451A09A1; Wed, 12 Feb 2014 06:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lR_LKSddrx-J; Wed, 12 Feb 2014 06:29:58 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 326B91A09A0; Wed, 12 Feb 2014 06:29:58 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 6BB1E7FC393; Wed, 12 Feb 2014 06:29:57 -0800 (PST) To: richih.mailinglist@gmail.com, kawamucho@mesh.ad.jp, kawashimam@vx.jp.nec.com Subject: [Errata Rejected] RFC5952 (3884) From: RFC Errata System Message-Id: <20140212142957.6BB1E7FC393@rfc-editor.org> Date: Wed, 12 Feb 2014 06:29:57 -0800 (PST) Cc: brian@innovationslab.net, ipv6@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 14:30:02 -0000 The following errata report has been rejected for RFC5952, "A Recommendation for IPv6 Address Text Representation". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5952&eid=3884 -------------------------------------- Status: Rejected Type: Technical Reported by: Richard Hartmann Date Reported: 2014-02-06 Rejected by: Brian Haberman (IESG) Section: 4.2.2. Original Text ------------- 4.2.2. Handling One 16-Bit 0 Field The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field. For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but 2001:db8::1:1:1:1:1 is not correct. Corrected Text -------------- 4.2.2. Incorrect use of "::" The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field. For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but 2001:db8::1:1:1:1:1 is not correct. The symbol "::" MUST NOT be used just so. For example, the representation 2001:db8:1:1:1:1:1:1 is correct, but 2001:db8:1:1::1:1:1:1 is not correct. Notes ----- You would think this should be obvious, but I have seen actual discussions that 2001:db8:1:1::1:1:1:1 is correct syntax. Explicitly forbidding this form does no harm and stops all discussions in this direction. Thanks for your work. --VERIFIER NOTES-- As agreed to by the document authors and the submitter, there is a reference to RFC 4291 that addresses the concern. -------------------------------------- RFC5952 (draft-ietf-6man-text-addr-representation-07) -------------------------------------- Title : A Recommendation for IPv6 Address Text Representation Publication Date : August 2010 Author(s) : S. Kawamura, M. Kawashima Category : PROPOSED STANDARD Source : IPv6 Maintenance Area : Internet Stream : IETF Verifying Party : IESG From internet-drafts@ietf.org Thu Feb 13 00:51:55 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 270B61A01AD; Thu, 13 Feb 2014 00:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9NyeF0EyhlE; Thu, 13 Feb 2014 00:51:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B5EA51A0177; Thu, 13 Feb 2014 00:51:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-multicast-addr-arch-update-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140213085149.4433.65554.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 00:51:49 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 08:51:55 -0000 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 : Updates to the IPv6 Multicast Addressing Architecture Authors : Mohamed Boucadair Stig Venaas Filename : draft-ietf-6man-multicast-addr-arch-update-03.txt Pages : 9 Date : 2014-02-13 Abstract: This document updates the IPv6 multicast addressing architecture by defining the 17-20 reserved bits as generic flag bits. The document provides also some clarifications related to the use of these flag bits. This document updates RFC 3956, RFC 3306 and RFC 4291. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-multicast-addr-arch-update/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-multicast-addr-arch-update-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-multicast-addr-arch-update-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 mohamed.boucadair@orange.com Thu Feb 13 00:59:09 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2346A1A0169 for ; Thu, 13 Feb 2014 00:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpTreAIAhPmV for ; Thu, 13 Feb 2014 00:59:07 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4A72F1A0176 for ; Thu, 13 Feb 2014 00:59:07 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 337833B4496 for ; Thu, 13 Feb 2014 09:59:05 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 1B68D35C061 for ; Thu, 13 Feb 2014 09:59:05 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Thu, 13 Feb 2014 09:59:04 +0100 From: To: "ipv6@ietf.org" Date: Thu, 13 Feb 2014 09:59:02 +0100 Subject: RE: I-D Action: draft-ietf-6man-multicast-addr-arch-update-03.txt Thread-Topic: I-D Action: draft-ietf-6man-multicast-addr-arch-update-03.txt Thread-Index: Ac8omOA+T/D4iJVrSkKyOTcKL3JxhQAAAoag Message-ID: <94C682931C08B048B7A8645303FDC9F36F4C31E952@PUEXCB1B.nanterre.francetelecom.fr> References: <20140213085149.4433.65554.idtracker@ietfa.amsl.com> In-Reply-To: <20140213085149.4433.65554.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.13.43018 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 08:59:09 -0000 Dear all, This new version integrates the comments received during the WGLC. The chan= ges are mainly editorial. Jouni/Tatuya can you please double check the new version and let us know if= the modifs solve your concerns? Thank you in advance. Errata can be also filled for each updated RFC. Cheers, Med >-----Message d'origine----- >De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de >internet-drafts@ietf.org >Envoy=E9=A0: jeudi 13 f=E9vrier 2014 09:52 >=C0=A0: i-d-announce@ietf.org >Cc=A0: ipv6@ietf.org >Objet=A0: I-D Action: draft-ietf-6man-multicast-addr-arch-update-03.txt > > >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 : Updates to the IPv6 Multicast Addressing >Architecture > Authors : Mohamed Boucadair > Stig Venaas > Filename : draft-ietf-6man-multicast-addr-arch-update-03.txt > Pages : 9 > Date : 2014-02-13 > >Abstract: > This document updates the IPv6 multicast addressing architecture by > defining the 17-20 reserved bits as generic flag bits. The document > provides also some clarifications related to the use of these flag > bits. > > This document updates RFC 3956, RFC 3306 and RFC 4291. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-6man-multicast-addr-arch- >update/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-6man-multicast-addr-arch-update-03 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-multicast-addr-arch- >update-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 nobody Thu Feb 13 11:07:15 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4715E1A034A for ; Thu, 13 Feb 2014 11:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-duL7z8Q95W for ; Thu, 13 Feb 2014 11:07:12 -0800 (PST) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 19C3C1A037E for ; Thu, 13 Feb 2014 11:07:11 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id cm18so16544373qab.23 for ; Thu, 13 Feb 2014 11:07:10 -0800 (PST) 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=YtVYXyxZnzcl8wLigJaH4eGwHO0UnG12rjkNFr+Fz4g=; b=yL/nKUYJ+1m8mzeJT7K4YR4fZbEhx5Pr06GU4Wy98ODk7L8JNEubpY5y2eB1AUhPYG RRAPIXCLFUkMSW+Nil7Z3tBAX4hXGwbRy7vyzMyg6Jr18SEfvoQDMmQ6Si+Qr6qX8ZIM Yvm+fy0mL1a3r/mmNWpeKxj20xfa9xmvf2xoC0ywCyn3r8L99aXNN7U3OgXEhxp0FVlU cQqPJ5znhALIsAvKT1ePQfLxQjfSK1lslOSFAGUQYsgMHKNe8mWrHjvfRSibYl7jyC/y J9AuNbIMI90xSS9xQ+dxCc9jhdQ9CrRX8Gn8zqtTL/0XxE3LhSOfjMhMGbShcTysxIkQ tcwQ== X-Received: by 10.224.49.69 with SMTP id u5mr5600154qaf.88.1392318430620; Thu, 13 Feb 2014 11:07:10 -0800 (PST) Received: from [10.86.246.61] (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id m14sm7924413qax.9.2014.02.13.11.07.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 11:07:08 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Comments on draft-ietf-6man-multicast-scopes-02 From: Ralph Droms In-Reply-To: Date: Thu, 13 Feb 2014 14:07:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: IPv6 IPv6 List X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/EoNOm0RBxeNEy7fzvcXB_R6NqEk Cc: draft-ietf-6man-multicast-scopes@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 19:07:14 -0000 I saw one comment posted during the WG last call on = draft-ietf-6man-multicast-scopes-02. Based on the discussion of that = comment, I will make the following changes to the document and post a = new revision before the cutoff on Monday. Section 3: OLD: o The boundaries of zones of a scope are defined by the IPv6 addressing architecture [RFC4291]. NEW: o The boundaries of zones of a scope are defined by the IPv6 addressing architecture [RFC4291] and updated by this document. Section 7: OLD: This document has no security considerations beyond those in RFC 4291 [RFC4291]. NEW: This document has no security considerations beyond those in RFC 4007 [RFC4007] and RFC 4291 [RFC4291]. Section 5: OLD: IANA is asked to establish a sub-registry titled "IPv6 Multicast Address Scopes" in the existing "Internet Protocol version 6 (IPv6) Multicast Address Allocations" registry. The "IPv6 Multicast Address Scopes" is to be populated with the scope values given in section 1, with a note associated with scope 3 listing all RFCs that define Realm-Local scoping rules that use scope 3. NEW: IANA is asked to establish a sub-registry titled "IPv6 Multicast Address Scopes" in the existing "Internet Protocol version 6 (IPv6) Multicast Address Allocations" registry. The "IPv6 Multicast Address Scopes" is to be populated with the scope values given in section 1. New definitions for scop values will be made with "IETF Review" policy. The registry will have a note associated with scope 3 listing all RFCs that define Realm-Local scoping rules that use scope 3. Section 1: OLD: 0 reserved 1 Interface-Local scope 2 Link-Local scope 3 Realm-Local scope 4 Admin-Local scope 5 Site-Local scope 6 (unassigned) 7 (unassigned) 8 Organization-Local scope 9 (unassigned) A (unassigned) B (unassigned) C (unassigned) D (unassigned) E Global scope F reserved NEW: +------+--------------------------+ | scop | NAME | +------+--------------------------+ | 0 | reserved | | 1 | Interface | | 2 | Link-Local scope | | 3 | Realm-Local scope | | 4 | Admin-Local scope | | 5 | Site-Local scope | | 6 | (unassigned) | | 7 | (unassigned) | | 8 | Organization-Local scope | | 9 | (unassigned) | | A | (unassigned) | | B | (unassigned) | | C | (unassigned) | | D | (unassigned) | | E | Global scope | | F | reserved | +------+--------------------------+ - Ralph From nobody Thu Feb 13 11:55:25 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FA11A0409 for ; Thu, 13 Feb 2014 11:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.922 X-Spam-Level: * X-Spam-Status: No, score=1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iclEcDnEOGy2 for ; Thu, 13 Feb 2014 11:55:21 -0800 (PST) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id F03EE1A0406 for ; Thu, 13 Feb 2014 11:55:20 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id u57so7924161wes.39 for ; Thu, 13 Feb 2014 11:55:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=F9bj7dHKv8IPcuwRytEIlcowy4fSkygNs4V6aGNuvj0=; b=fXB0m/By1noYZGoo2ajpE3HZjx2jAJqJEdKlL9JWDK2WXn+yrCDDjXPfl0gT3zrGON 52sFvxKoglh7XnRSxSISYWq9SJ3xojypyewtdQ4hH2nHQuWfwMx9Hnj7ozNZZ43x4RAu 1sVEVgPMdY93EMt5L45C/tePTPALdkZM/8E5MAppGUYEyDq1jBq/q+tPs6qwE2X5ZXkQ N+zgHabuxYAC5Gsmkz70xZ6mcgRmFXDagUMCioMzTzgKOaG6rDPzhXTKSUzkWioTXdbE x1ZV2FL6RxzHn9qKnE7noy+JWit6cgs6T0QIeqYu/ok9DMamivNjmua4Al+dLGD0sTnj ICPg== MIME-Version: 1.0 X-Received: by 10.180.72.239 with SMTP id g15mr7890468wiv.45.1392321318513; Thu, 13 Feb 2014 11:55:18 -0800 (PST) Sender: jinmei.tatuya@gmail.com Received: by 10.194.120.167 with HTTP; Thu, 13 Feb 2014 11:55:18 -0800 (PST) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F4C31E952@PUEXCB1B.nanterre.francetelecom.fr> References: <20140213085149.4433.65554.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4C31E952@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 13 Feb 2014 11:55:18 -0800 X-Google-Sender-Auth: zXBP_fiB7wyzFa6DHxdDi5sAddo Message-ID: Subject: Re: I-D Action: draft-ietf-6man-multicast-addr-arch-update-03.txt From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/fFs9NMkiT-YrQXtTvNyVEM5RGdE Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 19:55:22 -0000 At Thu, 13 Feb 2014 09:59:02 +0100, wrote: > This new version integrates the comments received during the WGLC. The changes are mainly editorial. > > Jouni/Tatuya can you please double check the new version and let us know if the modifs solve your concerns? Thank you in advance. This point in my original comment doesn't seem to be fully addressed: - In the NEW format of Section 4.2, this sentence may need to be revisited: In this case, the last 4 bits of the previously reserved field are interpreted as embedding the RP interface ID, as specified in this memo. In 03, the corresponding part is [..] When the R-bit is set, the last 4 bits of the previously reserved field are interpreted as embedding the RP interface ID, as specified in this memo. but it doesn't address my concern since the point is "the previously reserved" can be ambiguous. I also noticed this (weak) suggestion wasn't adopted: : Ah, okay. Maybe it's a distraction, but I'd consider adding a : "TERMINOLOGY" section or something, where we clarify the point (i.e., : the draft generally follows RFC 5952 to represent IPv6 addresses : except in citation of already published documents). But I'd leave it : to you. If ignoring it was your intent, that's fine. I'm pointing it out just in case it's overlooked. -- JINMEI, Tatuya From nobody Thu Feb 13 14:35:43 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890C61A0470 for ; Thu, 13 Feb 2014 14:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHP-ysxy0Cuu for ; Thu, 13 Feb 2014 14:35:36 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2C35B1A04C6 for ; Thu, 13 Feb 2014 14:35:35 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id u14so8652834lbd.37 for ; Thu, 13 Feb 2014 14:35:34 -0800 (PST) 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=903FYJ+cG/LBh8hc9xX+OX00XKcrWhFSFXp+5VqeSws=; b=clbVU20+6Rdof1uk/0XIkNDNO2L2JAZBYTjYpDpXEsJQ1JRaZ1Hpt10YS4b9f7bvYc OO/xuxiegqC4ZASPQm0upyPUwQj5lH4RqzUmWPUsOcmxlSo6SQdKZ0BZecXhpBGbS3S2 KWKu94Rngqdd9+y1nfOhPbZNipYlwq/pwdm4idBJlSsI5oTxm1ud7mcrsW8VhHNWHDsw 87dAgs8cvafk9QJ4Vces95gX93SBK7yXNE0y7v3IL4RDWdaAaIa9krHVKRszbWUX6TQ3 1J8PZ0GMgI1q768wOC2C8wwX1OsIMPmtKnYkw0KZUJFFaaKjExItfRlKIrWaP+SnTeib +MdQ== X-Received: by 10.112.45.108 with SMTP id l12mr2433913lbm.21.1392330934188; Thu, 13 Feb 2014 14:35:34 -0800 (PST) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id rt7sm3610894lbb.0.2014.02.13.14.35.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 14:35:33 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: I-D Action: draft-ietf-6man-multicast-addr-arch-update-03.txt From: Jouni Korhonen In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F4C31E952@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 14 Feb 2014 00:35:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140213085149.4433.65554.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4C31E952@PUEXCB1B.nanterre.francetelecom.fr> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/3kPgDZlpg0jbD5KNMfzX7GAAizY Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 22:35:38 -0000 Ok from my side. - Jouni On Feb 13, 2014, at 10:59 AM, mohamed.boucadair@orange.com wrote: > Dear all, >=20 > This new version integrates the comments received during the WGLC. The = changes are mainly editorial. >=20 > Jouni/Tatuya can you please double check the new version and let us = know if the modifs solve your concerns? Thank you in advance. >=20 > Errata can be also filled for each updated RFC. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part = de >> internet-drafts@ietf.org >> Envoy=E9 : jeudi 13 f=E9vrier 2014 09:52 >> =C0 : i-d-announce@ietf.org >> Cc : ipv6@ietf.org >> Objet : I-D Action: draft-ietf-6man-multicast-addr-arch-update-03.txt >>=20 >>=20 >> 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. >>=20 >> Title : Updates to the IPv6 Multicast Addressing >> Architecture >> Authors : Mohamed Boucadair >> Stig Venaas >> Filename : = draft-ietf-6man-multicast-addr-arch-update-03.txt >> Pages : 9 >> Date : 2014-02-13 >>=20 >> Abstract: >> This document updates the IPv6 multicast addressing architecture by >> defining the 17-20 reserved bits as generic flag bits. The document >> provides also some clarifications related to the use of these flag >> bits. >>=20 >> This document updates RFC 3956, RFC 3306 and RFC 4291. >>=20 >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-6man-multicast-addr-arch- >> update/ >>=20 >> There's also a htmlized version available at: >> = http://tools.ietf.org/html/draft-ietf-6man-multicast-addr-arch-update-03 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-multicast-addr-arch-= >> update-03 >>=20 >>=20 >> 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. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> 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 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Thu Feb 13 16:05:39 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF7B1A053B; Thu, 13 Feb 2014 16:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcTcIPuIWj-h; Thu, 13 Feb 2014 16:05:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC63A1A0052; Thu, 13 Feb 2014 16:05:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-multicast-scopes-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214000534.27397.15262.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 16:05:34 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/MLZpCKFWXU9IfE9MxJh9MxaYmz4 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 00:05:37 -0000 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 : IPv6 Multicast Address Scopes Author : Ralph Droms Filename : draft-ietf-6man-multicast-scopes-03.txt Pages : 5 Date : 2014-02-13 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-multicast-scopes-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 nobody Thu Feb 13 16:52:11 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5FB61A0051 for ; Thu, 13 Feb 2014 16:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hk9MWsReX302 for ; Thu, 13 Feb 2014 16:52:06 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 762711A002C for ; Thu, 13 Feb 2014 16:52:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=58282; q=dns/txt; s=iport; t=1392339124; x=1393548724; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TJWSHA+MkkXsIB9smzsbgONZeCYjTkDTlamMdDLWBr8=; b=MPHTpG1cBjGXvNjGB6FU/F100LYPVO/L6nHCvoDfZX3Kfsmu0zr6rJ4s Pqliz+bi9LrPu5vRYBqFks2tStHp9UHN9gdRPrrOxmi/94nOBhDWfP4PD BtinHOy30KCPS5IqkVVIXNUIjp8Bcp5nXiSEUOtvmaXHnfT3nQ+VGXvSb 0=; X-Files: draft-ietf-6man-multicast-scopes-03-from-2.diff.html : 41861 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAMtn/VKtJXHA/2dsb2JhbABZgwY4V79QgRkWdIImAQEELUMJEAIBCBImAQ0CMBcOAgQOE4d3DchbF44iCTMWBQeDJIEUAQOFWIpoh2yBMpBxgy2BaUE X-IronPort-AV: E=Sophos;i="4.95,841,1384300800"; d="html'217?scan'217,208,217";a="20347268" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-7.cisco.com with ESMTP; 14 Feb 2014 00:52:03 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1E0q3sO015255 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 00:52:03 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.245]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 18:52:03 -0600 From: "Ralph Droms (rdroms)" To: IPv6 IPv6 List Subject: Re: Comments on draft-ietf-6man-multicast-scopes-02 Thread-Topic: Comments on draft-ietf-6man-multicast-scopes-02 Thread-Index: AQHPKO7Ub78QyOFOHUWuPF5xJUyOuZq0UKiA Date: Fri, 14 Feb 2014 00:52:02 +0000 Message-ID: <30F57851-87B7-4260-B1C0-A56681020C9B@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.86.246.61] Content-Type: multipart/mixed; boundary="_002_30F5785187B74260B1C0A56681020C9Bciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/jZ3niwPDuLepu3jMrny4sSnuoGU Cc: "draft-ietf-6man-multicast-scopes@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 00:52:10 -0000 --_002_30F5785187B74260B1C0A56681020C9Bciscocom_ Content-Type: text/plain; charset="us-ascii" Content-ID: <2615E179D8C4CF429F3C71C37D59B60B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable draft-ietf-6man-multicast-scopes-03.txt addresses the comment posted during= the WG last call (see attached diff). In my opinion, this rev of the document is ready to be sent to the IESG. - Ralph --_002_30F5785187B74260B1C0A56681020C9Bciscocom_ Content-Type: text/html; name="draft-ietf-6man-multicast-scopes-03-from-2.diff.html" Content-Description: draft-ietf-6man-multicast-scopes-03-from-2.diff.html Content-Disposition: attachment; filename="draft-ietf-6man-multicast-scopes-03-from-2.diff.html"; size=41861; creation-date="Fri, 14 Feb 2014 00:52:02 GMT"; modification-date="Fri, 14 Feb 2014 00:52:02 GMT" Content-ID: <431AA513A8F84243AF57FA50FE5CFD9F@emea.cisco.com> Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPiANCjwhLS0gR2VuZXJhdGVkIGJ5IHJmY2RpZmYgMS4zMjogcmZjZGlmZiBkcmFmdC1p ZXRmLTZtYW4tbXVsdGljYXN0LXNjb3Blcy0wMi50eHQgZHJhZnQtaWV0Zi02bWFuLW11bHRpY2Fz dC1zY29wZXMtMDMudHh0IC0tPiANCjwhLS0gPCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0Mv L0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFsIiA+IC0tPg0KPCEtLSBTeXN0ZW06IERhcndpbiBy ZHJvbXMtbWFjIDEyLjUuMCBEYXJ3aW4gS2VybmVsIFZlcnNpb24gMTIuNS4wOiBTdW4gU2VwIDI5 IDEzOjMzOjQ3IFBEVCAyMDEzOyByb290OnhudS0yMDUwLjQ4LjEyfjEvUkVMRUFTRV9YODZfNjQg eDg2XzY0IC0tPiANCjwhLS0gVXNpbmcgYXdrOiAvdXNyL2Jpbi9hd2s6IGF3ayB2ZXJzaW9uIDIw MDcwNTAxIC0tPiANCjwhLS0gVXNpbmcgZGlmZjogL3Vzci9iaW4vZGlmZjogZGlmZiAoR05VIGRp ZmZ1dGlscykgMi44LjEgLS0+IA0KPCEtLSBVc2luZyB3ZGlmZjogOiAgLS0+IA0KPGh0bWw+IA0K PGhlYWQ+IA0KICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQv aHRtbDsgY2hhcnNldD1pc28tODg1OS0xIiAvPiANCiAgPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1TdHlsZS1UeXBlIiBjb250ZW50PSJ0ZXh0L2NzcyIgLz4gDQogIDx0aXRsZT5EaWZmOiBkcmFm dC1pZXRmLTZtYW4tbXVsdGljYXN0LXNjb3Blcy0wMi50eHQgLSBkcmFmdC1pZXRmLTZtYW4tbXVs dGljYXN0LXNjb3Blcy0wMy50eHQ8L3RpdGxlPiANCiAgPHN0eWxlIHR5cGU9InRleHQvY3NzIj4g DQogICAgYm9keSAgICB7IG1hcmdpbjogMC40ZXg7IG1hcmdpbi1yaWdodDogYXV0bzsgfSANCiAg ICB0ciAgICAgIHsgfSANCiAgICB0ZCAgICAgIHsgd2hpdGUtc3BhY2U6IHByZTsgZm9udC1mYW1p bHk6IG1vbm9zcGFjZTsgdmVydGljYWwtYWxpZ246IHRvcDsgZm9udC1zaXplOiAwLjg2ZW07fSAN CiAgICB0aCAgICAgIHsgZm9udC1zaXplOiAwLjg2ZW07IH0gDQogICAgLnNtYWxsICB7IGZvbnQt c2l6ZTogMC42ZW07IGZvbnQtc3R5bGU6IGl0YWxpYzsgZm9udC1mYW1pbHk6IFZlcmRhbmEsIEhl bHZldGljYSwgc2Fucy1zZXJpZjsgfSANCiAgICAubGVmdCAgIHsgYmFja2dyb3VuZC1jb2xvcjog I0VFRTsgfSANCiAgICAucmlnaHQgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgfSANCiAgICAu ZGlmZiAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0NDRjsgfSANCiAgICAubGJsb2NrIHsgYmFja2dy b3VuZC1jb2xvcjogI0JGQjsgfSANCiAgICAucmJsb2NrIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZG ODsgfSANCiAgICAuaW5zZXJ0IHsgYmFja2dyb3VuZC1jb2xvcjogIzhGRjsgfSANCiAgICAuZGVs ZXRlIHsgYmFja2dyb3VuZC1jb2xvcjogI0FDRjsgfSANCiAgICAudm9pZCAgIHsgYmFja2dyb3Vu ZC1jb2xvcjogI0ZGQjsgfSANCiAgICAuY29udCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsg fSANCiAgICAubGluZWJyIHsgYmFja2dyb3VuZC1jb2xvcjogI0FBQTsgfSANCiAgICAubGluZW5v IHsgY29sb3I6IHJlZDsgYmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgZm9udC1zaXplOiAwLjdlbTsg dGV4dC1hbGlnbjogcmlnaHQ7IHBhZGRpbmc6IDAgMnB4OyB9IA0KICAgIC5lbGlwc2lzeyBiYWNr Z3JvdW5kLWNvbG9yOiAjQUFBOyB9IA0KICAgIC5sZWZ0IC5jb250IHsgYmFja2dyb3VuZC1jb2xv cjogI0RERDsgfSANCiAgICAucmlnaHQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9 IA0KICAgIC5sYmxvY2sgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjOUQ5OyB9IA0KICAgIC5y YmxvY2sgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjREQ2OyB9IA0KICAgIC5pbnNlcnQgLmNv bnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjMEREOyB9IA0KICAgIC5kZWxldGUgLmNvbnQgeyBiYWNr Z3JvdW5kLWNvbG9yOiAjOEFEOyB9IA0KICAgIC5zdGF0cywgLnN0YXRzIHRkLCAuc3RhdHMgdGgg eyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyBwYWRkaW5nOiAycHggMDsgfSANCiAgPC9zdHlsZT4g DQo8L2hlYWQ+IA0KPGJvZHkgPiANCiAgPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIwIj4gDQogIDx0ciBiZ2NvbG9yPSJvcmFuZ2UiPjx0aD48L3RoPjx0aD4m bmJzcDtkcmFmdC1pZXRmLTZtYW4tbXVsdGljYXN0LXNjb3Blcy0wMi50eHQmbmJzcDs8L3RoPjx0 aD4gPC90aD48dGg+Jm5ic3A7ZHJhZnQtaWV0Zi02bWFuLW11bHRpY2FzdC1zY29wZXMtMDMudHh0 Jm5ic3A7PC90aD48dGg+PC90aD48L3RyPiANCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPkludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBSLiBEcm9tczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PkludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBSLiBEcm9tczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIENpc2NvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIENpc2NvPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDEiIC8+PC90ZD48L3Ry Pg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+VXBkYXRlczogUkZDIDQwMDcsIFJGQyA0MjkxIChpZiBhcHByb3ZlZCkgICAg ICAgICAgICAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPk5vdmVtYmVyIDExLCAyMDEzPC9zcGFuPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj5VcGRhdGVzOiBSRkMgNDAwNywgUkZDIDQy OTEgKGlmIGFwcHJvdmVkKSAgICAgICAgICAgICAgPHNwYW4gY2xhc3M9Imluc2VydCI+RmVicnVh cnkgMTQsIDIwMTQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij5JbnRlbmRlZCBzdGF0dXM6IFN0YW5kYXJkcyBUcmFjazwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkludGVuZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNr PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDIiIC8+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+RXhwaXJlczog PHNwYW4gY2xhc3M9ImRlbGV0ZSI+TWF5IDE1PC9zcGFuPiwgMjAxNDwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj5FeHBpcmVzOiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5BdWd1c3QgMTg8 L3NwYW4+LCAyMDE0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAg ICAgICAgIElQdjYgTXVsdGljYXN0IEFkZHJlc3MgU2NvcGVzPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgSVB2NiBNdWx0aWNhc3QgQWRkcmVzcyBT Y29wZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwMyIgLz48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAg ICAgICAgICAgICAgZHJhZnQtaWV0Zi02bWFuLW11bHRpY2FzdC1zY29wZXMtMDxzcGFuIGNsYXNz PSJkZWxldGUiPjI8L3NwYW4+LnR4dDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g ICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi02bWFuLW11bHRpY2FzdC1zY29wZXMtMDxzcGFuIGNs YXNzPSJpbnNlcnQiPjM8L3NwYW4+LnR4dDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5B YnN0cmFjdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkFic3RyYWN0PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMgZG9jdW1lbnQgdXBkYXRlcyB0aGUgZGVmaW5p dGlvbnMgb2YgSVB2NiBtdWx0aWNhc3Qgc2NvcGVzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIFRoaXMgZG9jdW1lbnQgdXBkYXRlcyB0aGUgZGVmaW5pdGlvbnMgb2YgSVB2NiBt dWx0aWNhc3Qgc2NvcGVzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5TdGF0dXMgb2Yg VGhpcyBNZW1vPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+U3RhdHVzIG9mIFRoaXMg TWVtbzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIEludGVybmV0LURyYWZ0 IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4g ZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3 OS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBwcm92aXNpb25zIG9mIEJDUCA3 OCBhbmQgQkNQIDc5LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJbnRlcm5ldC1E cmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZzwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29y a2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUYXNrIEZvcmNlIChJ RVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0 IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB3b3JraW5nIGRvY3VtZW50cyBhcyBJ bnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURy YWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBEcmFmdHMgaXMgYXQgaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RyYWZ0cy9jdXJyZW50Ly48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW50ZXJu ZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXgg bW9udGhzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW50ZXJuZXQtRHJhZnRz IGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBh bmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1l bnRzIGF0IGFueTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFuZCBtYXkgYmUg dXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55 PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJl ZmVyZW5jZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRpbWUuICBJdCBpcyBp bmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBtYXRlcmlh bCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90 aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDQiIC8+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg VGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiA8c3BhbiBjbGFzcz0iZGVsZXRlIj5N YXkgMTU8L3NwYW4+LCAyMDE0LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBU aGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkF1 Z3VzdCAxODwvc3Bhbj4sIDIwMTQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkNvcHly aWdodCBOb3RpY2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5Db3B5cmlnaHQgTm90 aWNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAw NSIgLz48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBDb3B5cmlnaHQgKGMpIDIwMTxzcGFuIGNsYXNz PSJkZWxldGUiPjM8L3NwYW4+IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQg YXMgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIENvcHlyaWdodCAoYykg MjAxPHNwYW4gY2xhc3M9Imluc2VydCI+NDwvc3Bhbj4gSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNv bnMgaWRlbnRpZmllZCBhcyB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2Vy dmVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRvY3VtZW50IGF1dGhvcnMu ICBBbGwgcmlnaHRzIHJlc2VydmVkLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBU aGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExl Z2FsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyBkb2N1bWVudCBpcyBz dWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUHJvdmlzaW9ucyBS ZWxhdGluZyB0byBJRVRGIERvY3VtZW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHM8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIChodHRwOi8vdHJ1c3Rl ZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNl bnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcHVibGljYXRpb24gb2YgdGhpcyBk b2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSBy ZXZpZXcgdGhlc2UgZG9jdW1lbnRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciBy aWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5k IHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBv bmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRy YWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGlj ZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFz IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMg YW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRl ZCB3aXRob3V0IHdhcnJhbnR5IGFzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5IiA+PHRkPjwvdGQ+PHRo PjxhIG5hbWU9InBhcnQtbDIiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+ PGVtPiBwYWdlIDIsIGxpbmUgMTU8L2VtPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0 LXIyIiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAyLCBs aW5lIDE4PC9lbT48L3RoPjx0ZD48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdXNlZCB0byBsaW1pdCB0 aGUgc2NvcGUgb2YgdGhlIG11bHRpY2FzdCBncm91cC4iIHNjb3AgMyBpcyBkZWZpbmVkIGFzPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdXNlZCB0byBsaW1pdCB0aGUgc2NvcGUg b2YgdGhlIG11bHRpY2FzdCBncm91cC4iIHNjb3AgMyBpcyBkZWZpbmVkIGFzPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAicmVzZXJ2ZWQi IGluIFJGQyA0MjkxLiAgVGhlIG11bHRpY2FzdCBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIGluPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgInJlc2VydmVkIiBpbiBSRkMgNDI5MS4g IFRoZSBtdWx0aWNhc3QgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBpbjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZHJhZnQtaWV0Zi1yb2xs LXRyaWNrbGUtbWNhc3QgW0ktRC5pZXRmLXJvbGwtdHJpY2tsZS1tY2FzdF0gZGVzaXJlczwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRyYWZ0LWlldGYtcm9sbC10cmlja2xlLW1j YXN0IFtJLUQuaWV0Zi1yb2xsLXRyaWNrbGUtbWNhc3RdIGRlc2lyZXM8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRvIHVzZSBtdWx0aWNh c3Qgc2NvcCAzIGZvciB0cmFuc3BvcnQgb2YgbXVsdGljYXN0IHRyYWZmaWMgc2NvcGVkIHRvPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdG8gdXNlIG11bHRpY2FzdCBzY29wIDMg Zm9yIHRyYW5zcG9ydCBvZiBtdWx0aWNhc3QgdHJhZmZpYyBzY29wZWQgdG88L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGEgbmV0d29yayBv ZiBub2RlcyBjb25uZWN0ZWQgaW4gYSBtZXNoLiAgVGhlIHVzZSBvZiB0aGlzIHNjb3AgdmFsdWU8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhIG5ldHdvcmsgb2Ygbm9kZXMgY29u bmVjdGVkIGluIGEgbWVzaC4gIFRoZSB1c2Ugb2YgdGhpcyBzY29wIHZhbHVlPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpcyB0byBhY2Nv bW1vZGF0ZSBhIG11bHRpY2FzdCBzY29wZSB0aGF0IGlzIGdyZWF0ZXIgdGhhbiBMaW5rLUxvY2Fs PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaXMgdG8gYWNjb21tb2RhdGUgYSBt dWx0aWNhc3Qgc2NvcGUgdGhhdCBpcyBncmVhdGVyIHRoYW4gTGluay1Mb2NhbDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYnV0IGlzIGFs c28gYXV0b21hdGljYWxseSBkZXRlcm1pbmVkIGJ5IHRoZSBuZXR3b3JrIGFyY2hpdGVjdHVyZS48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBidXQgaXMgYWxzbyBhdXRvbWF0aWNh bGx5IGRldGVybWluZWQgYnkgdGhlIG5ldHdvcmsgYXJjaGl0ZWN0dXJlLjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgZm9sbG93aW5nIHRhYmxlIHVwZGF0ZXMgdGhlIGRlZmlu aXRpb25zIGluIFJGQyA0MjkxOjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRo ZSBmb2xsb3dpbmcgdGFibGUgdXBkYXRlcyB0aGUgZGVmaW5pdGlvbnMgaW4gUkZDIDQyOTE6PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwNiIgLz48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj4wICByZXNlcnZlZDwv c3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imlu c2VydCI+ICAgKy0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSs8L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAg IDxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnwgc2NvcCB8IE5BTUUg ICAgICAgICAgICAgICAgICAgICB8PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj4xICBJ bnRlcmZhY2UtTG9jYWwgc2NvcGU8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICstLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICAgICA8c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9z cGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij58ICAwICAgfCByZXNlcnZlZCAgICAgICAgICAgICAgICAgfDwvc3Bhbj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgPHNw YW4gY2xhc3M9ImRlbGV0ZSI+MiAgTGluay1Mb2NhbCBzY29wZTwvc3Bhbj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+ICAgfCAgMSAgIHwg SW50ZXJmYWNlICAgICAgICAgICAgICAgIHw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgIDxzcGFuIGNsYXNzPSJkZWxl dGUiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg ICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnwgIDIgICB8IExpbmstTG9jYWwgc2NvcGUgICAgICAg ICB8PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj4zICBSZWFsbS1Mb2NhbCBzY29wZTwv c3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imlu c2VydCI+ICAgfCAgMyAgIHwgUmVhbG0tTG9jYWwgc2NvcGUgICAgICAgIHw8L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAg IDxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnwgIDQgICB8IEFkbWlu LUxvY2FsIHNjb3BlICAgICAgICB8PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj40ICBB ZG1pbi1Mb2NhbCBzY29wZTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+ICAgfCAgNSAgIHwgU2l0ZS1Mb2NhbCBzY29wZSAgICAg ICAgIHw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgICAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3NwYW4+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgIDxzcGFuIGNsYXNzPSJpbnNl cnQiPnwgIDYgICB8ICh1bmFzc2lnbmVkKSAgICAgICAgICAgICB8PC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA8c3BhbiBj bGFzcz0iZGVsZXRlIj41ICBTaXRlLUxvY2FsIHNjb3BlPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB8ICA3ICAgfCAodW5h c3NpZ25lZCkgICAgICAgICAgICAgfDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAg PHNwYW4gY2xhc3M9Imluc2VydCI+fCAgOCAgIHwgT3JnYW5pemF0aW9uLUxvY2FsIHNjb3BlIHw8 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPjYgICh1bmFzc2lnbmVkKTwvc3Bhbj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+ICAg fCAgOSAgIHwgKHVuYXNzaWduZWQpICAgICAgICAgICAgIHw8L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgIDxzcGFuIGNs YXNzPSJkZWxldGUiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnwgIEEgICB8ICh1bmFzc2lnbmVkKSAg ICAgICAgICAgICB8PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj43ICAodW5hc3NpZ25l ZCk8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNz PSJpbnNlcnQiPiAgIHwgIEIgICB8ICh1bmFzc2lnbmVkKSAgICAgICAgICAgICB8PC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICAgICA8c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9zcGFuPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij58ICBDICAgfCAo dW5hc3NpZ25lZCkgICAgICAgICAgICAgfDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ OCAgT3JnYW5pemF0aW9uLUxvY2FsIHNjb3BlPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB8ICBEICAgfCAodW5hc3NpZ25l ZCkgICAgICAgICAgICAgfDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgPHNwYW4g Y2xhc3M9Imluc2VydCI+fCAgRSAgIHwgR2xvYmFsIHNjb3BlICAgICAgICAgICAgIHw8L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPjkgICh1bmFzc2lnbmVkKTwvc3Bhbj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+ICAgfCAgRiAg IHwgcmVzZXJ2ZWQgICAgICAgICAgICAgICAgIHw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgIDxzcGFuIGNsYXNzPSJk ZWxldGUiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPistLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBBICAodW5hc3NpZ25lZCk8L3Nw YW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRl Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgQiAgKHVuYXNzaWduZWQpPC9zcGFuPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNs YXNzPSJkZWxldGUiPiAgIEMgICh1bmFzc2lnbmVkKTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3Nw YW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRl Ij4gICBEICAodW5hc3NpZ25lZCk8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9zcGFuPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgRSAgR2xv YmFsIHNjb3BlPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4g Y2xhc3M9ImRlbGV0ZSI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIEYgIHJlc2VydmVkPC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgVGhlIGZvbGxvd2luZyBjaGFuZ2UgaXMgYXBwbGllZCB0byBzZWN0aW9uIDIu NyBvZiBSRkMgNDI5MTo8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgZm9s bG93aW5nIGNoYW5nZSBpcyBhcHBsaWVkIHRvIHNlY3Rpb24gMi43IG9mIFJGQyA0MjkxOjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBPTEQ6PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgT0xEOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICBB ZG1pbi1Mb2NhbCBzY29wZSBpcyB0aGUgc21hbGxlc3Qgc2NvcGUgdGhhdCBtdXN0IGJlPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgQWRtaW4tTG9jYWwgc2NvcGUgaXMg dGhlIHNtYWxsZXN0IHNjb3BlIHRoYXQgbXVzdCBiZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgYWRtaW5pc3RyYXRpdmVseSBj b25maWd1cmVkLCBpLmUuLCBub3QgYXV0b21hdGljYWxseSBkZXJpdmVkPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgYWRtaW5pc3RyYXRpdmVseSBjb25maWd1cmVkLCBp LmUuLCBub3QgYXV0b21hdGljYWxseSBkZXJpdmVkPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICBmcm9tIHBoeXNpY2FsIGNvbm5l Y3Rpdml0eSBvciBvdGhlciwgbm9uLW11bHRpY2FzdC1yZWxhdGVkPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgICAgZnJvbSBwaHlzaWNhbCBjb25uZWN0aXZpdHkgb3Igb3Ro ZXIsIG5vbi1tdWx0aWNhc3QtcmVsYXRlZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgY29uZmlndXJhdGlvbi48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICBjb25maWd1cmF0aW9uLjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4NCiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5IiA+PHRkPjwvdGQ+PHRo PjxhIG5hbWU9InBhcnQtbDMiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+ PGVtPiBwYWdlIDQsIGxpbmUgMTQ8L2VtPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0 LXIzIiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSA0LCBs aW5lIDE0PC9lbT48L3RoPjx0ZD48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBPTEQ6PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg T0xEOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIG8gIFRoZSBib3VuZGFyaWVz IG9mIHpvbmVzIG9mIGEgc2NvcGUgb3RoZXIgdGhhbiBpbnRlcmZhY2UtbG9jYWwsPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICBvICBUaGUgYm91bmRhcmllcyBvZiB6b25lcyBv ZiBhIHNjb3BlIG90aGVyIHRoYW4gaW50ZXJmYWNlLWxvY2FsLDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICBsaW5rLWxvY2FsLCBh bmQgZ2xvYmFsIG11c3QgYmUgZGVmaW5lZCBhbmQgY29uZmlndXJlZCBieSBuZXR3b3JrPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICBsaW5rLWxvY2FsLCBhbmQgZ2xvYmFs IG11c3QgYmUgZGVmaW5lZCBhbmQgY29uZmlndXJlZCBieSBuZXR3b3JrPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgIGFkbWluaXN0 cmF0b3JzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgYWRtaW5pc3Ry YXRvcnMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE5FVzo8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBORVc6PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgbyAgVGhlIGJvdW5kYXJpZXMgb2Ygem9uZXMgb2YgYSBzY29wZSBhcmUgZGVmaW5lZCBi eSB0aGUgSVB2NjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgbyAgVGhlIGJv dW5kYXJpZXMgb2Ygem9uZXMgb2YgYSBzY29wZSBhcmUgZGVmaW5lZCBieSB0aGUgSVB2NjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk PjxhIG5hbWU9ImRpZmYwMDA3IiAvPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgYWRkcmVz c2luZyBhcmNoaXRlY3R1cmUgW1JGQzQyOTFdLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICAgICAgIGFkZHJlc3NpbmcgYXJjaGl0ZWN0dXJlIFtSRkM0MjkxXTxzcGFuIGNsYXNz PSJpbnNlcnQiPiBhbmQgdXBkYXRlZCBieSB0aGlzIGRvY3VtZW50PC9zcGFuPi48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+NC4gIERlZmluaXRpb24gb2YgUmVhbG0tTG9jYWwgU2NvcGUg Zm9yIElFRUUgODAyLjE1LjQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij40LiAgRGVm aW5pdGlvbiBvZiBSZWFsbS1Mb2NhbCBTY29wZSBmb3IgSUVFRSA4MDIuMTUuNDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBXaGVuIHVzZWQgaW4gYW4gSVAtb3Zlci1JRUVFODAyLjE1 LjQgbmV0d29yaywgInNjb3AgMyIgaXMgZGVmaW5lZCB0bzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIFdoZW4gdXNlZCBpbiBhbiBJUC1vdmVyLUlFRUU4MDIuMTUuNCBuZXR3b3Jr LCAic2NvcCAzIiBpcyBkZWZpbmVkIHRvPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpbmNsdWRlIGFsbCBpbnRlcmZhY2VzIHNoYXJpbmcg YSBQQU4gSUQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaW5jbHVkZSBhbGwg aW50ZXJmYWNlcyBzaGFyaW5nIGEgUEFOIElELjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij41LiAgSUFOQSBDb25zaWRlcmF0aW9uczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjUuICBJQU5BIENvbnNpZGVyYXRpb25zPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IElBTkEgaXMgYXNrZWQgdG8gZXN0YWJsaXNoIGEgc3ViLXJlZ2lzdHJ5IHRpdGxlZCAiSVB2NiBN dWx0aWNhc3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJQU5BIGlzIGFza2Vk IHRvIGVzdGFibGlzaCBhIHN1Yi1yZWdpc3RyeSB0aXRsZWQgIklQdjYgTXVsdGljYXN0PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBBZGRy ZXNzIFNjb3BlcyIgaW4gdGhlIGV4aXN0aW5nICJJbnRlcm5ldCBQcm90b2NvbCB2ZXJzaW9uIDYg KElQdjYpPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQWRkcmVzcyBTY29wZXMi IGluIHRoZSBleGlzdGluZyAiSW50ZXJuZXQgUHJvdG9jb2wgdmVyc2lvbiA2IChJUHY2KTwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk PjxhIG5hbWU9ImRpZmYwMDA4IiAvPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIE11bHRpY2FzdCBB ZGRyZXNzIEFsbG9jYXRpb25zIiByZWdpc3RyeS4gIFRoZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj4i SVB2NiBNdWx0aWNhc3QgQWRkcmVzczwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgTXVsdGljYXN0IEFkZHJlc3MgQWxsb2NhdGlvbnMiIHJlZ2lzdHJ5LiAgVGhlIDxz cGFuIGNsYXNzPSJpbnNlcnQiPm5ldyByZWdpc3RyeSBpcyB0byBiZTwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgPHNwYW4g Y2xhc3M9ImRlbGV0ZSI+U2NvcGVzIiBpcyB0byBiZSBwb3B1bGF0ZWQgd2l0aCB0aGUgc2NvcGUg dmFsdWVzIGdpdmVuIGluIHNlY3Rpb24gMSw8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnBvcHVsYXRlZCB3aXRoIHRoZSBzY29w ZSB2YWx1ZXMgZ2l2ZW4gaW4gc2VjdGlvbiAxLiAgTmV3IGRlZmluaXRpb25zPC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA8 c3BhbiBjbGFzcz0iZGVsZXRlIj53aXRoIGEgbm90ZSBhc3NvY2lhdGVkIHdpdGggc2NvcGUgMyBs aXN0aW5nIGFsbCBSRkNzIHRoYXQgZGVmaW5lPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5mb3Igc2NvcCB2YWx1ZXMgd2lsbCBi ZSBtYWRlIHdpdGggIklFVEYgUmV2aWV3IiBwb2xpY3kuICBUaGUgcmVnaXN0cnk8L3NwYW4+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB3 aWxsIGhhdmUgYSBub3RlIGFzc29jaWF0ZWQgd2l0aCBzY29wZSAzIGxpc3RpbmcgYWxsIFJGQ3Mg dGhhdCBkZWZpbmU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBSZWFsbS1Mb2NhbCBzY29waW5nIHJ1bGVzIHRoYXQgdXNlIHNj b3BlIDMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUmVhbG0tTG9jYWwgc2Nv cGluZyBydWxlcyB0aGF0IHVzZSBzY29wZSAzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij42LiAgQWNrbm93bGVkZ21lbnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Ni4g IEFja25vd2xlZGdtZW50czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBSb2JlcnQg Q3JhZ2llLCBLZXJyeSBMeW5uLCBKaW5tZWkgVGF0dXlhLCBEYXZlIFRoYWxlciBhbmQgU3RpZyBW ZW5hYXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBSb2JlcnQgQ3JhZ2llLCBL ZXJyeSBMeW5uLCBKaW5tZWkgVGF0dXlhLCBEYXZlIFRoYWxlciBhbmQgU3RpZyBWZW5hYXM8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFs bCBjb250cmlidXRlZCB0ZXh0IGFuZC9vciByZXZpZXcgdG8gZW5zdXJlIHRoYXQgdGhlIHVwZGF0 ZXMgdG8gUkZDPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYWxsIGNvbnRyaWJ1 dGVkIHRleHQgYW5kL29yIHJldmlldyB0byBlbnN1cmUgdGhhdCB0aGUgdXBkYXRlcyB0byBSRkM8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IDQwMDcgYW5kIFJGQyA0MjkxIGFyZSBjb3JyZWN0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgNDAwNyBhbmQgUkZDIDQyOTEgYXJlIGNvcnJlY3Q8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+Ny4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+Ny4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPg0KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwOSIgLz48L3RkPjwvdHI+DQog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj4gICBUaGlzIGRvY3VtZW50IGhhcyBubyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBi ZXlvbmQgdGhvc2UgaW4gUkZDIDQ8c3BhbiBjbGFzcz0iZGVsZXRlIj4yOTE8L3NwYW4+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFRoaXMgZG9jdW1lbnQgaGFzIG5vIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIGJleW9uZCB0aG9zZSBpbiBSRkMgNDxzcGFuIGNsYXNzPSJpbnNl cnQiPjAwNzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgW1JGQzQyOTFdLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICBbUkZDNDxzcGFuIGNsYXNzPSJpbnNlcnQiPjAwN10gYW5kIFJGQyA0MjkxIFtSRkM0 PC9zcGFuPjI5MV0uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjguICBSZWZlcmVuY2Vz PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+OC4gIFJlZmVyZW5jZXM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+OC4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXM8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij44LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlczwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBbUkZDNDAwN10gIERlZXJpbmcsIFMuLCBIYWJlcm1h biwgQi4sIEppbm1laSwgVC4sIE5vcmRtYXJrLCBFLiwgYW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgW1JGQzQwMDddICBEZWVyaW5nLCBTLiwgSGFiZXJtYW4sIEIuLCBKaW5t ZWksIFQuLCBOb3JkbWFyaywgRS4sIGFuZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBCLiBaaWxsLCAiSVB2NiBTY29w ZWQgQWRkcmVzcyBBcmNoaXRlY3R1cmUiLCBSRkMgNDAwNyw8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAgICAgICAgICAgIEIuIFppbGwsICJJUHY2IFNjb3BlZCBBZGRyZXNzIEFy Y2hpdGVjdHVyZSIsIFJGQyA0MDA3LDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBNYXJjaCAyMDA1LjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgTWFyY2ggMjAwNS48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW1JGQzQyOTFdICBIaW5kZW4sIFIuIGFuZCBTLiBEZWVy aW5nLCAiSVAgVmVyc2lvbiA2IEFkZHJlc3Npbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBbUkZDNDI5MV0gIEhpbmRlbiwgUi4gYW5kIFMuIERlZXJpbmcsICJJUCBWZXJzaW9u IDYgQWRkcmVzc2luZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBBcmNoaXRlY3R1cmUiLCBSRkMgNDI5MSwgRmVicnVh cnkgMjAwNi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIEFy Y2hpdGVjdHVyZSIsIFJGQyA0MjkxLCBGZWJydWFyeSAyMDA2LjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij44LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+OC4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlczwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBbSS1ELmlldGYtcm9sbC10cmlja2xlLW1jYXN0XTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtJLUQuaWV0Zi1yb2xsLXRyaWNrbGUtbWNhc3Rd PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICAgICAgICAgIEh1aSwgSi4gYW5kIFIuIEtlbHNleSwgIk11bHRpY2FzdCBQcm90b2NvbCBm b3IgTG93IHBvd2VyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAg ICBIdWksIEouIGFuZCBSLiBLZWxzZXksICJNdWx0aWNhc3QgUHJvdG9jb2wgZm9yIExvdyBwb3dl cjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgICAgICAgICBhbmQgTG9zc3kgTmV0d29ya3MgKE1QTCkiLCBkcmFmdC1pZXRmLXJvbGwt dHJpY2tsZS08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIGFu ZCBMb3NzeSBOZXR3b3JrcyAoTVBMKSIsIGRyYWZ0LWlldGYtcm9sbC10cmlja2xlLTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRkPjxh IG5hbWU9ImRpZmYwMDEwIiAvPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAgICAgbWNh c3QtMDxzcGFuIGNsYXNzPSJkZWxldGUiPjUgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBBdWd1c3QgMjAx Mzwvc3Bhbj4uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAg bWNhc3QtMDxzcGFuIGNsYXNzPSJpbnNlcnQiPjYgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBKYW51YXJ5 IDIwMTQ8L3NwYW4+LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+DQogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBbSUVFRTgwMi4x NS40XTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtJRUVFODAyLjE1LjRdPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAg ICAgICAgICAgIElFRUUgU3RkIDgwMi4xNS40LTIwMDYsICJJRUVFIFN0YW5kYXJkIGZvciBJbmZv cm1hdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgSUVF RSBTdGQgODAyLjE1LjQtMjAwNiwgIklFRUUgU3RhbmRhcmQgZm9yIEluZm9ybWF0aW9uPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAg ICAgICAgIHRlY2hub2xvZ3kgLSBUZWxlY29tbXVuaWNhdGlvbnMgYW5kIGluZm9ybWF0aW9uIGV4 Y2hhbmdlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICB0ZWNo bm9sb2d5IC0gVGVsZWNvbW11bmljYXRpb25zIGFuZCBpbmZvcm1hdGlvbiBleGNoYW5nZTwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+DQogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg ICAgICAgICBiZXR3ZWVuIHN5c3RlbXMgLSBMb2NhbCBhbmQgbWV0cm9wb2xpdGFuIGFyZWEgbmV0 d29ya3MgLTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgYmV0 d2VlbiBzeXN0ZW1zIC0gTG9jYWwgYW5kIG1ldHJvcG9saXRhbiBhcmVhIG5ldHdvcmtzIC08L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg ICAgICAgICAgU3BlY2lmaWMgcmVxdWlyZW1lbnRzOyBQYXJ0IDE1LjQ6IFdpcmVsZXNzIE1lZGl1 bSBBY2Nlc3M8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIFNw ZWNpZmljIHJlcXVpcmVtZW50czsgUGFydCAxNS40OiBXaXJlbGVzcyBNZWRpdW0gQWNjZXNzPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAg ICAgICAgICAgIENvbnRyb2wgKE1BQykgYW5kIFBoeXNpY2FsIExheWVyIChQSFkpIFNwZWNpZmlj YXRpb25zIGZvcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAg Q29udHJvbCAoTUFDKSBhbmQgUGh5c2ljYWwgTGF5ZXIgKFBIWSkgU3BlY2lmaWNhdGlvbnMgZm9y PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4NCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICAgICAgICAgIExvdy1SYXRlIFdpcmVsZXNzIFBlcnNvbmFsIEFyZWEgTmV0d29ya3MgKFdQ QU5zKSIsIE9jdG9iZXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAg ICAgIExvdy1SYXRlIFdpcmVsZXNzIFBlcnNvbmFsIEFyZWEgTmV0d29ya3MgKFdQQU5zKSIsIE9j dG9iZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgICAgICAgICAgICAgMjAwNi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAgICAgICAgICAgIDIwMDYuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4NCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPg0KDQogICAgIDx0cj48dGQ+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkPjwvdGQ+PC90cj4NCiAgICAgPHRyIGJnY29sb3I9ImdyYXkiPjx0aCBjb2xzcGFuPSI1 IiBhbGlnbj0iY2VudGVyIj48YSBuYW1lPSJlbmQiPiZuYnNwO0VuZCBvZiBjaGFuZ2VzLiAxMCBj aGFuZ2UgYmxvY2tzLiZuYnNwOzwvYT48L3RoPjwvdHI+DQogICAgIDx0ciBjbGFzcz0ic3RhdHMi Pjx0ZD48L3RkPjx0aD48aT40MyBsaW5lcyBjaGFuZ2VkIG9yIGRlbGV0ZWQ8L2k+PC90aD48dGg+ PGk+IDwvaT48L3RoPjx0aD48aT4zMyBsaW5lcyBjaGFuZ2VkIG9yIGFkZGVkPC9pPjwvdGg+PHRk PjwvdGQ+PC90cj4NCiAgICAgPHRyPjx0ZCBjb2xzcGFuPSI1IiBhbGlnbj0iY2VudGVyIiBjbGFz cz0ic21hbGwiPjxici8+VGhpcyBodG1sIGRpZmYgd2FzIHByb2R1Y2VkIGJ5IHJmY2RpZmYgMS4z Mi4gVGhlIGxhdGVzdCB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBmcm9tIDxhIGhyZWY9Imh0dHA6Ly93 d3cubGV2a293ZXR6LmNvbS9pZXRmL3Rvb2xzL3JmY2RpZmYvIiA+aHR0cDovL3d3dy5sZXZrb3dl dHouY29tL2lldGYvdG9vbHMvcmZjZGlmZi88L2E+IDwvdGQ+PC90cj4NCiAgIDwvdGFibGU+DQog ICA8L2JvZHk+DQogICA8L2h0bWw+DQo= --_002_30F5785187B74260B1C0A56681020C9Bciscocom_-- From nobody Thu Feb 13 22:59:48 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071951A0136 for ; Thu, 13 Feb 2014 22:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.249 X-Spam-Level: X-Spam-Status: No, score=-0.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtzG9hgmIuym for ; Thu, 13 Feb 2014 22:59:45 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B6B0E1A00E3 for ; Thu, 13 Feb 2014 22:59:44 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 80DD93B42B2; Fri, 14 Feb 2014 07:59:42 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 6728A2380AD; Fri, 14 Feb 2014 07:59:42 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Fri, 14 Feb 2014 07:59:41 +0100 From: To: =?utf-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 14 Feb 2014 07:59:41 +0100 Subject: RE: I-D Action: draft-ietf-6man-multicast-addr-arch-update-03.txt Thread-Topic: I-D Action: draft-ietf-6man-multicast-addr-arch-update-03.txt Thread-Index: Ac8o9YXv3n/x9VQBTGeEnpNYfsAyyQAWlPGA Message-ID: <94C682931C08B048B7A8645303FDC9F36F4D2529F3@PUEXCB1B.nanterre.francetelecom.fr> References: <20140213085149.4433.65554.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4C31E952@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/ckq5Uo0afmuafrr2GVwSfo2t59c Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 06:59:47 -0000 RGVhciBUYXR1eWEsDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQpDaGVlcnMsDQpNZWQNCg0KPi0t LS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPkRlwqA6IGppbm1laS50YXR1eWFAZ21haWwuY29t IFttYWlsdG86amlubWVpLnRhdHV5YUBnbWFpbC5jb21dIERlIGxhIHBhcnQNCj5kZSA/Pz8/DQo+ RW52b3nDqcKgOiBqZXVkaSAxMyBmw6l2cmllciAyMDE0IDIwOjU1DQo+w4DCoDogQk9VQ0FEQUlS IE1vaGFtZWQgSU1UL09MTg0KPkNjwqA6IGlwdjZAaWV0Zi5vcmcNCj5PYmpldMKgOiBSZTogSS1E IEFjdGlvbjogZHJhZnQtaWV0Zi02bWFuLW11bHRpY2FzdC1hZGRyLWFyY2gtdXBkYXRlLTAzLnR4 dA0KPg0KPkF0IFRodSwgMTMgRmViIDIwMTQgMDk6NTk6MDIgKzAxMDAsDQo+PG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20+IHdyb3RlOg0KPg0KPj4gVGhpcyBuZXcgdmVyc2lvbiBpbnRlZ3Jh dGVzIHRoZSBjb21tZW50cyByZWNlaXZlZCBkdXJpbmcgdGhlIFdHTEMuIFRoZQ0KPmNoYW5nZXMg YXJlIG1haW5seSBlZGl0b3JpYWwuDQo+Pg0KPj4gSm91bmkvVGF0dXlhIGNhbiB5b3UgcGxlYXNl IGRvdWJsZSBjaGVjayB0aGUgbmV3IHZlcnNpb24gYW5kIGxldCB1cyBrbm93DQo+aWYgdGhlIG1v ZGlmcyBzb2x2ZSB5b3VyIGNvbmNlcm5zPyBUaGFuayB5b3UgaW4gYWR2YW5jZS4NCj4NCj5UaGlz IHBvaW50IGluIG15IG9yaWdpbmFsIGNvbW1lbnQgZG9lc24ndCBzZWVtIHRvIGJlIGZ1bGx5IGFk ZHJlc3NlZDoNCj4NCj4tIEluIHRoZSBORVcgZm9ybWF0IG9mIFNlY3Rpb24gNC4yLCB0aGlzIHNl bnRlbmNlIG1heSBuZWVkIHRvIGJlDQo+ICByZXZpc2l0ZWQ6DQo+DQo+ICAgICAgSW4gdGhpcyBj YXNlLCB0aGUgbGFzdCA0DQo+ICAgICAgYml0cyBvZiB0aGUgcHJldmlvdXNseSByZXNlcnZlZCBm aWVsZCBhcmUgaW50ZXJwcmV0ZWQgYXMgZW1iZWRkaW5nDQo+ICAgICAgdGhlIFJQIGludGVyZmFj ZSBJRCwgYXMgc3BlY2lmaWVkIGluIHRoaXMgbWVtby4NCj4NCj5JbiAwMywgdGhlIGNvcnJlc3Bv bmRpbmcgcGFydCBpcw0KPg0KPiAgIFsuLl0gV2hlbiB0aGUNCj4gICBSLWJpdCBpcyBzZXQsIHRo ZSBsYXN0IDQgYml0cyBvZiB0aGUgcHJldmlvdXNseSByZXNlcnZlZCBmaWVsZCBhcmUNCj4gICBp bnRlcnByZXRlZCBhcyBlbWJlZGRpbmcgdGhlIFJQIGludGVyZmFjZSBJRCwgYXMgc3BlY2lmaWVk IGluIHRoaXMgbWVtby4NCj4NCj5idXQgaXQgZG9lc24ndCBhZGRyZXNzIG15IGNvbmNlcm4gc2lu Y2UgdGhlIHBvaW50IGlzICJ0aGUgcHJldmlvdXNseQ0KPnJlc2VydmVkIiBjYW4gYmUgYW1iaWd1 b3VzLg0KDQpbTWVkXSBCdXQgdGhhdCBzZW50ZW5jZSBpcyBhbG1vc3QgdGhlIHNhbWUgYXMgaW4g UkZDMzk1NjogDQoNCiIuLi50aGUgbGFzdCA0DQogICBiaXRzIG9mIHRoZSBwcmV2aW91c2x5IHJl c2VydmVkIGZpZWxkIGFyZSBpbnRlcnByZXRlZCBhcyBlbWJlZGRpbmcNCiAgIHRoZSBSUCBpbnRl cmZhY2UgSUQsIGFzIHNwZWNpZmllZCBpbiB0aGlzIG1lbW8uICINCg0KVGhhdCB0ZXh0IHNob3Vs ZCBiZSBpbnRlcnByZXRlZCBpbiB0aGUgY29udGV4dCBvZiBSRkMzOTU2LiANCg0KPg0KPkkgYWxz byBub3RpY2VkIHRoaXMgKHdlYWspIHN1Z2dlc3Rpb24gd2Fzbid0IGFkb3B0ZWQ6DQo+DQo+OiBB aCwgb2theS4gIE1heWJlIGl0J3MgYSBkaXN0cmFjdGlvbiwgYnV0IEknZCBjb25zaWRlciBhZGRp bmcgYQ0KPjogIlRFUk1JTk9MT0dZIiBzZWN0aW9uIG9yIHNvbWV0aGluZywgd2hlcmUgd2UgY2xh cmlmeSB0aGUgcG9pbnQgKGkuZS4sDQo+OiB0aGUgZHJhZnQgZ2VuZXJhbGx5IGZvbGxvd3MgUkZD IDU5NTIgdG8gcmVwcmVzZW50IElQdjYgYWRkcmVzc2VzDQo+OiBleGNlcHQgaW4gY2l0YXRpb24g b2YgYWxyZWFkeSBwdWJsaXNoZWQgZG9jdW1lbnRzKS4gIEJ1dCBJJ2QgbGVhdmUgaXQNCj46IHRv IHlvdS4NCj4NCj5JZiBpZ25vcmluZyBpdCB3YXMgeW91ciBpbnRlbnQsIHRoYXQncyBmaW5lLiAg SSdtIHBvaW50aW5nIGl0IG91dCBqdXN0DQo+aW4gY2FzZSBpdCdzIG92ZXJsb29rZWQuDQpbTWVk XSBUaGlzIGNvbW1lbnQgd2FzIGluY2x1ZGVkOiBzZWUgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi02bWFuLW11bHRpY2FzdC1hZGRyLWFyY2gtdXBkYXRlLTAzI3NlY3Rpb24t MSAgDQoNCiAgIFRleHR1YWwgcmVwcmVzZW50YXRpb24gb2YgSVB2NiBhZGRyZXNzZXMgaW5jbHVk ZWQgaW4gdGhlIFJGQyB1cGRhdGVzDQogICBmb2xsb3dzIHRoZSByZWNvbW1lbmRhdGlvbiBpbiBb UkZDNTk1Ml0uDQoNCj4NCj4tLQ0KPkpJTk1FSSwgVGF0dXlhDQo= From nobody Fri Feb 14 01:11:56 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872061A0179 for ; Fri, 14 Feb 2014 01:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYg3enGwt-FB for ; Fri, 14 Feb 2014 01:11:51 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id CB3191A00DC for <6man@ietf.org>; Fri, 14 Feb 2014 01:11:50 -0800 (PST) Received: from [2001:5c0:1000:a::fab] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WEEnL-0002Pu-CX; Fri, 14 Feb 2014 10:10:51 +0100 Message-ID: <52FDDA1B.3060104@si6networks.com> Date: Fri, 14 Feb 2014 05:55:55 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mark ZZZ Smith , Fernando Gont , Ole Troan Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <52F1B8CE.4070803@ericsson.com> <52F1BD1F.2080007@si6networks.com> <52F383A0.7030002@si6networks.com> <52F44A73.3000609@si6networks.com> <86BA587E-A7F8-47B9-AC74-98D3DB9A7E46@employees.org> <52F4DDC7.8070606@si6networks.com> <1391817989.71306.YahooMailNeo@web162204.mail.bf1.yahoo.com> <52F927E0.5080706@gont.com.ar> <1392193724.5329.YahooMailNeo@web162201.mail.bf1.yahoo.com> In-Reply-To: <1392193724.5329.YahooMailNeo@web162201.mail.bf1.yahoo.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/nWjw2b3ZNNV6fWdR2fGs2Mox0uw Cc: Thomas Narten , "C. M. Heard" , Tim Chown , "6man@ietf.org" <6man@ietf.org>, Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 09:11:53 -0000 Hi, Mark, On 02/12/2014 05:28 AM, Mark ZZZ Smith wrote: >> Depends on what you mean by end-to-end crypto, and in what >> context. >> >> SSL/TLS for say, web servers and mailservers, fine. >> >> IPsec for the general case...mmm.. unlikely. >> >> Is there any plan for solving the authentication of nodes? Is >> everyone expected to get/buy a certificate? >> > > Any or all of them. In the latter case, BTNS mode of IPsec (RFC5386) > would probably be better than NSA can have everything(tm) IP because > it shrinks their window to be a MITM. Which my result in "placebo" security: you never know if you've been MITM'ed. :-( >>> I think it might be worth remembering that as per the IETF88 >>> Plenary, end-to-end encryption is the general direction, and that >>> middle boxes less effective/in-effective because of it. So >>> putting a lot of time and effort into facilitating them might be >>> wasted effort. >> >> It's a 1-page to 5-page document (and that's including >> bolierplates). > > I'm not saying to no do it, just that if e.g., somebody like Google, > Apple or Microsoft roll out an update that enables crypto on a very > popular service (similar to how within days, millions of iPhones and > iPads used MPTCP for Siri), the traffic that these middleboxes are > inspecting might "go dark" or become hidden "overnight". If e.g. TLS is enabled, the TCP header information is still in the clear (unless you're *tunneling* over TLS). > If there is > a lot of effort involved, it would be wasted if that sort of event > happened. This shouldn't be "a lot of effort". >>> Yes, it works! Thanks Kristian. However here in Italy 3G carriers >>> filter out TCP options.. so SIRI gives up and stops trying to use >>> mptcp in the long run. > > "Encapsulation of TCP and other Transport Protocols over UDP" > http://tools.ietf.org/html/draft-cheshire-tcp-over-udp-00 > > "In fact, TCP options are expected to work more reliably with > TCP-over-UDP, because middleboxes will be less able to easily > interfere with such options, modifying them, stripping them, or > dropping packets containing TCP options, as they often dotoday with > native TCP packets. In particular, Multipath > TCP-over-UDP is expected to work more reliably than native Multipath > TCP [RFC6824], because middleboxes that interfere with use of those > TCP options will be less able to do that when the packets are > encapsulated inside UDP." > > ;-) Well, how good this is probably depends on whether one assumes the aforementioned middle-box behavior is intentional or not. If it is, then this is "middle-box unfriendly". If it's not, this is "middle-box friendly". FWIW, one would expect this to be an arms race. If this is *intended middle-box behavior", then you'd expect middle-boxes to become smarter, and eventually we'll have TCP-over-UDP-over-* :-) Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Feb 14 10:44:10 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE5B1A0318; Fri, 14 Feb 2014 10:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDgF8ZrqbpaQ; Fri, 14 Feb 2014 10:43:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2241A034E; Fri, 14 Feb 2014 10:43:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-ipv6-address-generation-privacy-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214184335.29433.45425.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 10:43:35 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/q_Z6HtJrJIjIbMRrZ0o94jdyq0M Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 18:44:04 -0000 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 : Privacy Considerations for IPv6 Address Generation Mechanisms Authors : Alissa Cooper Fernando Gont Dave Thaler Filename : draft-ietf-6man-ipv6-address-generation-privacy-01.txt Pages : 16 Date : 2014-02-14 Abstract: This document discusses privacy and security considerations for several IPv6 address generation mechanisms, both standardized and non-standardized. It evaluates how different mechanisms mitigate different threats and the trade-offs that implementors, developers, and users face in choosing different addresses or address generation mechanisms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-address-generation-privacy/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-ipv6-address-generation-privacy-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ipv6-address-generation-privacy-01 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 nobody Fri Feb 14 10:53:55 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94C51A037D for ; Fri, 14 Feb 2014 10:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyUWtfZmIPPC for ; Fri, 14 Feb 2014 10:53:49 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id 477521A02EE for ; Fri, 14 Feb 2014 10:53:49 -0800 (PST) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 5E9EB208D1 for ; Fri, 14 Feb 2014 13:53:47 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 14 Feb 2014 13:53:47 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:message-id:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mesmtp; bh=Rm7EniDZbC Eo8Jo1lSyIP7zjZVU=; b=Ns8FG8IvFPshHThlXH1G11oViPqIEDGF1iGhLTGQQI 3cIzxUr+s7zJJv46XkJFgc1xf8jWskpHUwxq+H7Jnq7CTOkd/TJb7k0ynfYKk84r 6K8dX+8vv7N8L0PfaJHXkU2MrDEQdPr7ofv3/GhSNrgAVn6HuIwrUmC0qsAb/zp7 4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=Rm7EniDZbCEo8Jo1lSyIP7 zjZVU=; b=s1bn+jynx/hBKuARIOLKvfR+5SoC9EgnWqeD+XZQI/W/AmGz2DMvcR gYNDBfLbGdVKxo91t87lsg77gaZHzyc3oYMGtUUQTbUZYpeSAUon0YXvPw2nLXPI UeiWNKlheCOcQCQ5ubW1lun2bYjIQq4QLOiHAPPUxfTToDgBbycsE= X-Sasl-enc: bF5oYOt60P/jsQc3dKOyl+In6/99hbScZj676nyCC7lT 1392404026 Received: from [171.68.18.50] (unknown [171.68.18.50]) by mail.messagingengine.com (Postfix) with ESMTPA id 7AF60C007AC for ; Fri, 14 Feb 2014 13:53:46 -0500 (EST) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Fri, 14 Feb 2014 10:53:41 -0800 Subject: Re: I-D Action: draft-ietf-6man-ipv6-address-generation-privacy-01.txt From: Alissa Cooper To: Message-ID: Thread-Topic: I-D Action: draft-ietf-6man-ipv6-address-generation-privacy-01.txt References: <20140214184335.29433.45425.idtracker@ietfa.amsl.com> In-Reply-To: <20140214184335.29433.45425.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/OLhrD767_h8WxQeu_ION8jHaHs4 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 18:53:54 -0000 Summary of changes: Additional text about unique prefix assignment in Sec 4 Updated table entries in Sec 4 to reflect discussion at IETF 88 Corrected Sec 4.4 text on CGAs Added detail to Sec 4.7 to reflect common DHCPv6 practices Alissa On 2/14/14 10:43 AM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the IPv6 Maintenance Working Group of the >IETF. > > Title : Privacy Considerations for IPv6 Address >Generation Mechanisms > Authors : Alissa Cooper > Fernando Gont > Dave Thaler > Filename : draft-ietf-6man-ipv6-address-generation-privacy-01.txt > Pages : 16 > Date : 2014-02-14 > >Abstract: > This document discusses privacy and security considerations for > several IPv6 address generation mechanisms, both standardized and > non-standardized. It evaluates how different mechanisms mitigate > different threats and the trade-offs that implementors, developers, > and users face in choosing different addresses or address generation > mechanisms. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-address-generation-p >rivacy/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-6man-ipv6-address-generation-privacy >-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ipv6-address-generation-p >rivacy-01 > > >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 nobody Fri Feb 14 12:36:14 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA961A0388 for ; Fri, 14 Feb 2014 12:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwT-FZeu_5my for ; Fri, 14 Feb 2014 12:36:08 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0E81A02F5 for ; Fri, 14 Feb 2014 12:36:08 -0800 (PST) Received: from mail147-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.22; Fri, 14 Feb 2014 20:36:06 +0000 Received: from mail147-ch1 (localhost [127.0.0.1]) by mail147-ch1-R.bigfish.com (Postfix) with ESMTP id 868E518025B for ; Fri, 14 Feb 2014 20:36:06 +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(z579ehz9371I936eI542Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2fh109h2a8h839h93fhd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh9a9j1155h) Received-SPF: pass (mail147-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:(10009001)(6009001)(199002)(189002)(13464003)(377424004)(377454003)(56776001)(93136001)(93516002)(2656002)(76176001)(47976001)(54316002)(94316002)(15202345003)(50986001)(49866001)(47736001)(94946001)(87266001)(85306002)(95666001)(74366001)(95416001)(19580395003)(80022001)(74316001)(66066001)(65816001)(83322001)(69226001)(19580405001)(79102001)(59766001)(77982001)(76796001)(92566001)(33646001)(63696002)(74876001)(76576001)(74662001)(74502001)(31966008)(47446002)(74706001)(76482001)(80976001)(54356001)(77096001)(46102001)(76786001)(4396001)(81542001)(86362001)(83072002)(87936001)(81816001)(81686001)(15975445006)(90146001)(56816005)(53806001)(81342001)(51856001)(85852003)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB442; H:CO1PR05MB442.namprd05.prod.outlook.com; CLIP:66.129.241.14; FPR:BC4ACD3A.94F223C2.E7F1A163.C8DAD0D0.202EB; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail147-ch1 (localhost.localdomain [127.0.0.1]) by mail147-ch1 (MessageSwitch) id 1392410163994987_9470; Fri, 14 Feb 2014 20:36:03 +0000 (UTC) Received: from CH1EHSMHS001.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.236]) by mail147-ch1.bigfish.com (Postfix) with ESMTP id EF19A24008D for ; Fri, 14 Feb 2014 20:36:03 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 14 Feb 2014 20:36:02 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.411.0; Fri, 14 Feb 2014 20:35:58 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) with Microsoft SMTP Server (TLS) id 15.0.878.16; Fri, 14 Feb 2014 20:35:56 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.51]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.51]) with mapi id 15.00.0878.008; Fri, 14 Feb 2014 20:35:56 +0000 From: Ronald Bonica To: "ipv6@ietf.org" Subject: FW: New Version Notification for draft-gont-6man-lla-opt-validation-00.txt Thread-Topic: New Version Notification for draft-gont-6man-lla-opt-validation-00.txt Thread-Index: AQHPKZSs4evcaGY/OEyKE8jiUJpmpZq1NV3A Date: Fri, 14 Feb 2014 20:35:55 +0000 Message-ID: <4cb5b8b8622048479255c9f6c42abac5@CO1PR05MB442.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-forefront-prvs: 01221E3973 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% Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/6u7XjRCMwzhOn9HsAwUFqCxezOI X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 20:36:12 -0000 Rm9sa3MsDQoNClBsZWFzZSByZXZpZXcgYW5kIHByb3ZpZGUgY29tbWVudHMuDQoNCiAgICAgICAg ICAgICAgICAgICBSb24NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSAN ClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMTQsIDIwMTQgOTo1NCBBTQ0KVG86IFNodWNoZW5nIExJ VSAoV2lsbCk7IFdpbGwgTGl1OyBGZXJuYW5kbyBHb250OyBSb25hbGQgQm9uaWNhOyBGZXJuYW5k byBHb250OyBSb25hbGQgQm9uaWNhDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWdvbnQtNm1hbi1sbGEtb3B0LXZhbGlkYXRpb24tMDAudHh0DQoNCg0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWdvbnQtNm1hbi1sbGEtb3B0LXZhbGlkYXRpb24tMDAudHh0 DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEZlcm5hbmRvIEdvbnQgYW5kIHBv c3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtZ29udC02bWFuLWxs YS1vcHQtdmFsaWRhdGlvbg0KUmV2aXNpb246CTAwDQpUaXRsZToJCVZhbGlkYXRpb24gb2YgTmVp Z2hib3IgRGlzY292ZXJ5IFNvdXJjZSBMaW5rLUxheWVyIEFkZHJlc3MgKFNMTEEpIGFuZCBUYXJn ZXQgTGluay1sYXllciBBZGRyZXNzIChUTExBKSBvcHRpb25zDQpEb2N1bWVudCBkYXRlOgkyMDE0 LTAyLTE0DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxMA0KVVJMOiAg ICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWdvbnQt Nm1hbi1sbGEtb3B0LXZhbGlkYXRpb24tMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ29udC02bWFuLWxsYS1vcHQtdmFsaWRhdGlv bi8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nb250 LTZtYW4tbGxhLW9wdC12YWxpZGF0aW9uLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlzIG1lbW8g ZG9jdW1lbnRzIHR3byBzY2VuYXJpb3MgaW4gd2hpY2ggYW4gb24tbGluayBhdHRhY2tlciBlbWl0 cw0KICAgYSBjcmFmdGVkIElQdjYgTmVpZ2hib3IgRGlzY292ZXJ5IChORCkgcGFja2V0IHRoYXQg cG9pc29ucyBpdHMNCiAgIHZpY3RpbSdzIG5laWdoYm9yIGNhY2hlLiAgSW4gdGhlIGZpcnN0IHNj ZW5hcmlvLCB0aGUgYXR0YWNrZXIgY2F1c2VzDQogICBhIHZpY3RpbSB0byBtYXAgYSBsb2NhbCBJ UHY2IGFkZHJlc3MgdG8gYSBsb2NhbCByb3V0ZXIncyBvd24gbGluay0NCiAgIGxheWVyIGFkZHJl c3MuICBJbiB0aGUgc2Vjb25kIHNjZW5hcmlvLCB0aGUgYXR0YWNrZXIgY2F1c2VzIHRoZQ0KICAg dmljdGltIHRvIG1hcCBhIHVuaWNhc3QgSVAgYWRkcmVzcyB0byBhIGxpbmsgbGF5ZXIgYnJvYWRj YXN0IGFkZHJlc3MuDQogICBJbiBib3RoIHNjZW5hcmlvcywgdGhlIGF0dGFja2VyIGNhbiBleHBs b2l0IHRoZSBwb2lzb25lZCBuZWlnaGJvcg0KICAgY2FjaGUgdG8gcGVyZm9ybSBhIHN1YnNlcXVl bnQgZm9yd29yZGluZy1sb29wIGF0dGFjaywgdGh1cw0KICAgcG90ZW50aWFsbHkgY2F1c2luZyBh IERlbmlhbCBvZiBTZXJ2aWNlLg0KDQogICBGaW5hbGx5LCB0aGlzIG1lbW8gc3BlY2lmaWVzIHNp bXBsZSB2YWxpZGF0aW9ucyB0aGF0IHRoZSByZWNpcGllbnQgb2YNCiAgIGFuIE5EIG1lc3NhZ2Ug Y2FuIGV4ZWN1dGUgaW4gb3JkZXIgdG8gcHJvdGVjdCBpdHNlbGYgYWdhaW5zdCB0aGUNCiAgIGFi b3ZlLW1lbnRpb25lZCB0aHJlYXRzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0K UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K DQoNCg0K From nobody Fri Feb 14 13:10:46 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188931A031D for ; Fri, 14 Feb 2014 08:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wtwpvZreiST for ; Fri, 14 Feb 2014 08:57:59 -0800 (PST) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A66891A0319 for <6man@ietf.org>; Fri, 14 Feb 2014 08:57:58 -0800 (PST) Received: by mail-pb0-f42.google.com with SMTP id jt11so12603587pbb.29 for <6man@ietf.org>; Fri, 14 Feb 2014 08:57:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Wwyr5N+Ei1uFOTF3IukYLvlA6+o0K0y8UaN2LjF4+yo=; b=vW+1lfUTRxGvByl9R1ANlOeO5dtrGNcsh8F4yt/I6/AwOLFzJyNFBJU+1Dc9noBHZg fbOsDiOjnLiVdocv3Bdwoj7enffKQi15N3vOx0wR8t3IHbnrKuhx15oX8B9fEKPZKSvP SCjtro+HFPMQZJtRfhXALn4D9TyppWjEImjPTZYcmsC405Yl5KYGz9oDKCXZRFuV4zfU v+pbCqrL+BPXGrIontPw92D4uYRL1veYbi8QDl3ZAT5Vaj/CQERy66LGqlrk9XawVBKz 5KSsXOpFAyoudkCGyrMUP1PuSK0ieW/9GwcNKEFALNA6gMZjBKyKpqCC1zaJ2U0xvgrP sMaw== X-Received: by 10.68.201.97 with SMTP id jz1mr10426633pbc.26.1392397077051; Fri, 14 Feb 2014 08:57:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.104.66 with HTTP; Fri, 14 Feb 2014 08:57:36 -0800 (PST) In-Reply-To: <52FDDA1B.3060104@si6networks.com> References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <52F1B8CE.4070803@ericsson.com> <52F1BD1F.2080007@si6networks.com> <52F383A0.7030002@si6networks.com> <52F44A73.3000609@si6networks.com> <86BA587E-A7F8-47B9-AC74-98D3DB9A7E46@employees.org> <52F4DDC7.8070606@si6networks.com> <1391817989.71306.YahooMailNeo@web162204.mail.bf1.yahoo.com> <52F927E0.5080706@gont.com.ar> <1392193724.5329.YahooMailNeo@web162201.mail.bf1.yahoo.com> <52FDDA1B.3060104@si6networks.com> From: =?UTF-8?Q?Dan_L=C3=BCdtke?= Date: Fri, 14 Feb 2014 17:57:36 +0100 Message-ID: Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/xck_8n2dlj5w_3rr3gLFAB5vTTI X-Mailman-Approved-At: Fri, 14 Feb 2014 13:10:42 -0800 Cc: Thomas Narten , "6man@ietf.org" <6man@ietf.org>, "C. M. Heard" , Tim Chown , Suresh Krishnan , Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 16:58:01 -0000 We all do not know what the future might bring, so being able to differentiate between an unknown IPv6 extension header and an unknown upper layer header should not be considered unimportant. I prefer reserving a range over creating a new registry. The main reason is that I am developing IPv6 software and it is easier to keep the parsing tree short. E.g. exthdr->option vs. exthdr->subexthdr->option Some nitpicking: In section "3. Problem Statement": typo: "on the fat" -> "on the fa_c_t" In section "5. Operation of the UEH": typo: "discusses de operation" -> "discusses _the_ operation" That's all for now, have a nice weekend everyone. -- Dan Luedtke http://www.danrl.de From nobody Fri Feb 14 13:10:48 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DF31A035C for ; Fri, 14 Feb 2014 09:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_66=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hahvsbXptALP for ; Fri, 14 Feb 2014 09:36:16 -0800 (PST) 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 D01CB1A0361 for <6man@ietf.org>; Fri, 14 Feb 2014 09:36:08 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id rq2so12661767pbb.3 for <6man@ietf.org>; Fri, 14 Feb 2014 09:36:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/CS/ik8KF1Uh0zL+t2JQ1bqbWbXyQY+EUt9TnXvzVJ0=; b=O0Nk8aoADKjKepGhVYDGFF/O4aylyBLejRbdiR2z1ozU9vIfhzV2qi8zfok9Q6fEZA odreCp6eM8ZaHBrM35kvvGao3qWen3D1mp8iu6S2IFX43UUQ8BcOlGfY0+/3Esrpa4Oj /eVdwwzrFp5+pR+AO2u9VmTJ/6VNS+WplExcf4xXx/XJd+AoXXKLoX5EN9fMxJJqfhLt 1miQYRS1unIFTdCJyxK/gARuq5BrW6zVTyKXOdm6lesGpuxWUz7UyYq+uwnD4P5PW5rP rPHqOOOwUW7t/XuWaXHPb8T7OUBxx6VSHMos78lD0MY4INNnUoeWZ0z9cKMD17/NejaV K3eA== X-Received: by 10.66.159.233 with SMTP id xf9mr10517830pab.139.1392399367390; Fri, 14 Feb 2014 09:36:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.104.66 with HTTP; Fri, 14 Feb 2014 09:35:47 -0800 (PST) In-Reply-To: References: <20140210213947.14657.20184.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?Dan_L=C3=BCdtke?= Date: Fri, 14 Feb 2014 18:35:47 +0100 Message-ID: Subject: Re: New Version Notification for draft-sarikaya-6man-next-hop-ra-00.txt To: sarikaya@ieee.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/pIKshYk6viw4N9TtrRq3VYSt5fY X-Mailman-Approved-At: Fri, 14 Feb 2014 13:10:43 -0800 Cc: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 17:36:19 -0000 Hi, I have very mixed feelings regarding this draft and I have not yet decided whether it is me or the draft :) I just throw my first thoughts in. I might get more verbose later or next week. Just pick up what you think is helpful and maybe improve the draft or help me understand why some of the options and fields the way they are. The Route Prefix option from section 7 has a field called Metric. It is "only" 3 bit long. How was this value chosen? Why not something that fits perfectly into a more standard type like uint8_t or uint16_t? And why not the usual preference which is 2 bits wide and allows to assign low/medium/high/reserved values? Did I miss the reasoning for the field's width in the preceding text? In section 10 the field "prefix" is said to be 16 octets or less in length. Please make clear that the size MUST always be a multiple of 16 octets. Please do not specify a field containing a prefix that is smaller than sizeof(struct in6_addr). We developers will eventually fill the field using inet_pton() and the last thing we want to do is to apply bit-magic and/or variable length voodoo. I am sure you have thought about that it is just the text that is a bit misleading here. All options, except the modified Route Prefix option, have a bad alignment. Starting an IPv6 address or prefix at the 3rd octet of an option is probably not the best idea. If possible use multiples of 4 or better 8 octets as starting point. Just one example: Section 13 Figure 7 could be re-aligned without wasting anything: BAD: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Next Hop Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Prefix Length |Resvd|Prf|Metric| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix (Variable Length) | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GOOD: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length |Resvd|Prf|Metr.| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Next Hop Address + + + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Source Address + + + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix (Variable Length) | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Despite these formal objections I am still in the process of understanding how the proposed solution would work in the field. The Next Hop Address option for example can be used alone. Is this right? And if so, why would I want this? And to what prefixes does the option apply? How is this different from a default gateway? In Section 14 you use MUST. This will probably lead to discussion. I don't think a MUST is required there. SHOULD or MAY is enough, since these are only considerations. MUST is always something an implementer gets a headache from :) I also have the feeling that consuming 7 numbers from the registry for new options is a bit too greedy. Do you see any way to reduce the consumption of this very limited resource? I think it would help supporting the draft a lot. The usual nitpicking: Section 4: "eroor" -> "error" Section 5: "document.The" -> document.[WHITESPACE]The" Section 7: Figure 1: Metric is too long. It breaks the figure. Maybe call it "Mtr." in the figure. Section 7: Field Definition: There is a colon (:) missing after the first "Metric". Same in Section 11 Figure 5, Section 12 Figure 6 and Section 13 Figure 7. Section 8: Figure 2: It is unclear how long the last field is. This is _very_ confusing for everybody implementing the draft. Section 9: Figure 3: It is unclear how long the last field is. Same as above. Hope that helps and have a nice weekend! Dan -- Dan Luedtke http://www.danrl.de From nobody Fri Feb 14 13:44:36 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D561A032B for ; Fri, 14 Feb 2014 13:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSZVH6lbB2Iu for ; Fri, 14 Feb 2014 13:44:32 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 794471A02EE for ; Fri, 14 Feb 2014 13:44:32 -0800 (PST) Received: from BL2PR03CA021.namprd03.prod.outlook.com (10.141.66.29) by BY2PR03MB027.namprd03.prod.outlook.com (10.255.240.41) with Microsoft SMTP Server (TLS) id 15.0.878.16; Fri, 14 Feb 2014 21:44:22 +0000 Received: from BY2FFO11FD025.protection.gbl (2a01:111:f400:7c0c::188) by BL2PR03CA021.outlook.office365.com (2a01:111:e400:c1b::29) with Microsoft SMTP Server (TLS) id 15.0.873.15 via Frontend Transport; Fri, 14 Feb 2014 21:44:22 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD025.mail.protection.outlook.com (10.1.15.214) with Microsoft SMTP Server (TLS) id 15.0.868.13 via Frontend Transport; Fri, 14 Feb 2014 21:44:21 +0000 Received: from TK5EX14MBXC302.redmond.corp.microsoft.com ([169.254.2.226]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0174.002; Fri, 14 Feb 2014 21:43:36 +0000 From: Christian Huitema To: Alissa Cooper , "ipv6@ietf.org" Subject: RE: I-D Action: draft-ietf-6man-ipv6-address-generation-privacy-01.txt Thread-Topic: I-D Action: draft-ietf-6man-ipv6-address-generation-privacy-01.txt Thread-Index: AQHPKbTGum4CxepzqEuRLO1ZYGGEqZq1GL6AgAArHPA= Date: Fri, 14 Feb 2014 21:43:36 +0000 Message-ID: References: <20140214184335.29433.45425.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(189002)(199002)(51704005)(44976005)(59766001)(79102001)(80976001)(56776001)(74366001)(95416001)(55846006)(77982001)(65816001)(6806004)(66066001)(50986001)(63696002)(54316002)(80022001)(33656001)(20776003)(83322001)(47776003)(85306002)(50466002)(23726002)(95666001)(81816001)(81686001)(51856001)(47976001)(74706001)(46102001)(76482001)(54356001)(53806001)(4396001)(47736001)(2656002)(46406003)(87266001)(47446002)(49866001)(31966008)(74662001)(85852003)(56816005)(74502001)(92726001)(92566001)(94316002)(87936001)(74876001)(90146001)(93516002)(81542001)(86362001)(76796001)(83072002)(69226001)(81342001)(86612001)(94946001)(77096001)(76786001)(93136001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB027; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:1C94FF3D.AD0AC20B.78D11FBB.CE1DEBD.20268; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 01221E3973 X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/0BM-aGJa9ImwBSqNuKOnsPVdM0s X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 21:44:35 -0000 > Summary of changes: > > Additional text about unique prefix assignment in Sec 4 > > Updated table entries in Sec 4 to reflect discussion at IETF 88 >=20 > Corrected Sec 4.4 text on CGAs >=20 > Added detail to Sec 4.7 to reflect common DHCPv6 practices I read this draft, and while I generally agree with the discussion, I feel = that a particular angle is missing, the relation between IPv6 address and M= AC address tracking. There are tracking systems that can record and correlate the MAC addresses = of mobile nodes as they connect to various networks. The obvious countermea= sure is to randomize the MAC address. On a Wi-Fi network, it could be done = by passively listening to the advertisement from the access point, and then= making an explicit decision to use a stable MAC address if the location is= trusted, and a randomized one if it is not. The question then is whether the IPv6 would remain constant even if the MAC= address changed. There are generation schemes where the address would rema= in constant. CGA for example only depends of the IPv6 header and the public= key. Stable IID would remain constant if the network interface parameter u= sed in the generation (Net_Iface) remained constant, e.g. was based on the = interface name. It would obviously change if the interface was identified b= y the MAC address. Can we add a discussion of the issue to this address privacy draft? -- Christian Huitema From nobody Fri Feb 14 14:18:07 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5BE1A01D1 for ; Fri, 14 Feb 2014 14:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbkXi_J_6BcL for ; Fri, 14 Feb 2014 14:17:41 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 16B941A00FA for ; Fri, 14 Feb 2014 14:17:40 -0800 (PST) Received: from [2001:5c0:1400:a::dfb] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WER4h-0005Jk-BW; Fri, 14 Feb 2014 23:17:35 +0100 Message-ID: <52FE95ED.7090900@si6networks.com> Date: Fri, 14 Feb 2014 19:17:17 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Christian Huitema , Alissa Cooper , "ipv6@ietf.org" Subject: Re: I-D Action: draft-ietf-6man-ipv6-address-generation-privacy-01.txt References: <20140214184335.29433.45425.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/eoyIdFKDML61jKIVaIdpXgCOW24 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 22:17:52 -0000 Hi, Christian, On 02/14/2014 06:43 PM, Christian Huitema wrote: > I read this draft, and while I generally agree with the discussion, I > feel that a particular angle is missing, the relation between IPv6 > address and MAC address tracking. > > There are tracking systems that can record and correlate the MAC > addresses of mobile nodes as they connect to various networks. Yes, as e.g.: . > The > obvious countermeasure is to randomize the MAC address. This has issues. Do you randomize the the whole six bytes of the address? Not that MAC addresses are guaranteed to be unique (MAC address duplication is well-known) -- but if you do randomize the MAC address, the collisions are of course more likely. Besides do you randomize it each time you connect to a network? If you do, you might end up with a different IPv6 address each time (this will be guaranteed if your doing traditional SLAAC, but may be the case with stable-privacy if you employ the mac address as the interface_id). While this wouldn't be an issue for the roam around cyber-cafes scenario, it is probably not desirable for e.g. enterprises. Also, what if I want to keep my TCP connections open in the presence of a temporal link disconnection? So it looks like you'd want to implement some sort of stable-privacy but for the MAC address... > The question then is whether the IPv6 would remain constant even if > the MAC address changed. There are generation schemes where the > address would remain constant. CGA for example only depends of the > IPv6 header and the public key. Stable IID would remain constant if > the network interface parameter used in the generation (Net_Iface) > remained constant, e.g. was based on the interface name. It would > obviously change if the interface was identified by the MAC address. (Apologies for responding before reading your whole message :-) ) > Can we add a discussion of the issue to this address privacy draft? I personally have no issues. My only "concern" is that if we start discussing IDs other than the IPv6 addresses, we might later discuss e.g. layer-7 stuff. Not that layer-2 and layer-7 privacy issues are uninteresting.. but rather than the more focused we stay, the more tractable the problem is. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Feb 14 16:24:40 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E07A1A0158 for ; Fri, 14 Feb 2014 16:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NN9HiqUsn1Zp for ; Fri, 14 Feb 2014 16:24:37 -0800 (PST) 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 34EEE1A0140 for ; Fri, 14 Feb 2014 16:24:36 -0800 (PST) Received: from DM2PR03CA007.namprd03.prod.outlook.com (10.141.52.155) by BLUPR03MB589.namprd03.prod.outlook.com (10.255.124.35) with Microsoft SMTP Server (TLS) id 15.0.878.16; Sat, 15 Feb 2014 00:24:32 +0000 Received: from BN1BFFO11FD038.protection.gbl (2a01:111:f400:7c10::1:155) by DM2PR03CA007.outlook.office365.com (2a01:111:e400:2414::27) with Microsoft SMTP Server (TLS) id 15.0.878.16 via Frontend Transport; Sat, 15 Feb 2014 00:24:32 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD038.mail.protection.outlook.com (10.58.144.101) with Microsoft SMTP Server (TLS) id 15.0.868.13 via Frontend Transport; Sat, 15 Feb 2014 00:24:31 +0000 Received: from TK5EX14MBXC302.redmond.corp.microsoft.com ([169.254.2.226]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0174.002; Sat, 15 Feb 2014 00:23:54 +0000 From: Christian Huitema To: Fernando Gont , Alissa Cooper , "ipv6@ietf.org" Subject: RE: I-D Action: draft-ietf-6man-ipv6-address-generation-privacy-01.txt Thread-Topic: I-D Action: draft-ietf-6man-ipv6-address-generation-privacy-01.txt Thread-Index: AQHPKbTGum4CxepzqEuRLO1ZYGGEqZq1GL6AgAArHPCAAA3GgIAAIkxg Date: Sat, 15 Feb 2014 00:23:54 +0000 Message-ID: References: <20140214184335.29433.45425.idtracker@ietfa.amsl.com> <52FE95ED.7090900@si6networks.com> In-Reply-To: <52FE95ED.7090900@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(199002)(189002)(51704005)(47976001)(50986001)(47736001)(69226001)(49866001)(74706001)(55846006)(74662001)(47446002)(74502001)(76796001)(85306002)(77096001)(31966008)(80976001)(44976005)(87266001)(4396001)(56776001)(59766001)(53806001)(86612001)(95416001)(54316002)(23726002)(76482001)(74366001)(51856001)(95666001)(87936001)(77982001)(46102001)(54356001)(81542001)(50466002)(74876001)(6806004)(56816005)(92566001)(81816001)(90146001)(81342001)(2656002)(81686001)(86362001)(80022001)(33656001)(63696002)(94946001)(93136001)(47776003)(93516002)(79102001)(46406003)(83322001)(20776003)(94316002)(92726001)(83072002)(66066001)(65816001)(85852003)(60764002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB589; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:BFD6C6D1.2F1A479A.41E89F8B.4CC2FC71.201A7; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 012349AD1C X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/nzPGJ9SVmf2kEEe9yoGiagnnRhQ X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 00:24:39 -0000 >> Can we add a discussion of the issue to this address privacy draft? > > I personally have no issues. My only "concern" is that if we start discus= sing IDs other than the IPv6 addresses, we might later discuss e.g. layer-7= stuff. Not that layer-2 and layer-7 privacy issues are uninteresting.. but= rather than the more focused we stay, the more tractable the problem is. I would not want to discuss in an IPv6 draft the precise mechanics of chang= ing MAC addresses, or the policy controls to make avoid nasty side effects.= I would like to see a simple issue debated: "assuming that the host admini= strator has programmed the host to change its MAC address before visiting n= etwork X, can we guarantee that the IPv6 IID does not leak information abou= t the identity of the host." -- Christian Huitema From nobody Fri Feb 14 16:45:53 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9BC1A0047 for ; Fri, 14 Feb 2014 16:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPF2mmGb4EAx for ; Fri, 14 Feb 2014 16:45:49 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id A81971A000C for ; Fri, 14 Feb 2014 16:45:49 -0800 (PST) Received: from [2001:5c0:1400:a::dfb] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WETO3-0001g2-AK; Sat, 15 Feb 2014 01:45:43 +0100 Message-ID: <52FEB7DA.7070506@si6networks.com> Date: Fri, 14 Feb 2014 21:42:02 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Christian Huitema , Alissa Cooper , "ipv6@ietf.org" Subject: Re: I-D Action: draft-ietf-6man-ipv6-address-generation-privacy-01.txt References: <20140214184335.29433.45425.idtracker@ietfa.amsl.com> <52FE95ED.7090900@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/VT0ltwekt1KBIfQ3s9Ej0yzVWk8 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 00:45:52 -0000 Hi, Christian, On 02/14/2014 09:23 PM, Christian Huitema wrote: >> >> I personally have no issues. My only "concern" is that if we start >> discussing IDs other than the IPv6 addresses, we might later >> discuss e.g. layer-7 stuff. Not that layer-2 and layer-7 privacy >> issues are uninteresting.. but rather than the more focused we >> stay, the more tractable the problem is. > > I would not want to discuss in an IPv6 draft the precise mechanics of > changing MAC addresses, or the policy controls to make avoid nasty > side effects. I would like to see a simple issue debated: "assuming > that the host administrator has programmed the host to change its MAC > address before visiting network X, can we guarantee that the IPv6 IID > does not leak information about the identity of the host." My simple answer would be "Depends on the algorithm employed to generated the IID". For example, if you do the traditional SLAAC IIDs, "randomizing the MAC adress" would essentially mitigate the privacy/security issues related with IPv6 addressing. OTOH, if the node implements Microsoft's scheme (randomized but constant IIDs along the life of the node), then I'd expect to randomized MACs to just mitigate the MAC-tracking issue. (I don't think they regenerate the IID when the NIC is replaced.. buy I might be wrong). P.S.: While we won't be able to commit any of these before the IETF meeting, I will craft some text and post it here for discussion asap. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Feb 14 19:37:29 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6ACF1A001F for ; Fri, 14 Feb 2014 19:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.401 X-Spam-Level: X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i27b_AH5jYjm for ; Fri, 14 Feb 2014 19:37:26 -0800 (PST) Received: from nm47-vm8.bullet.mail.bf1.yahoo.com (nm47-vm8.bullet.mail.bf1.yahoo.com [216.109.115.143]) by ietfa.amsl.com (Postfix) with ESMTP id 45AF41A0018 for ; Fri, 14 Feb 2014 19:37:26 -0800 (PST) Received: from [98.139.212.149] by nm47.bullet.mail.bf1.yahoo.com with NNFMP; 15 Feb 2014 03:37:24 -0000 Received: from [98.139.212.239] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 15 Feb 2014 03:37:24 -0000 Received: from [127.0.0.1] by omp1048.mail.bf1.yahoo.com with NNFMP; 15 Feb 2014 03:37:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 437722.78389.bm@omp1048.mail.bf1.yahoo.com Received: (qmail 69269 invoked by uid 60001); 15 Feb 2014 03:37:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1392435444; bh=ZUMemRYEtfxIRBnE2bYVikZ8U1u68xRF95DCtc9tUpk=; 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=GY9Ykz/W/Zl4XgDb2N6P9tbFTGo3IGwml0Bsc5Xl8gNBH8ehihiitCpsAQoxPggtc2aeUWwipmlWdJqECSXUMh5+eOJMGEv1K6ODhUHABWWENSiHbKRD9FsDPcYI1/tPVqn7ni3wl1d63h3uBpDc1miVhfALd7MIZ+N3jV9U38w= 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=IQQd1qQ3mKiYxMZKGo/YIZ6lVi4T2gdUAdhxekaZyHUt8Nsr70WxW1dG+bxHr5fYXgUfXUnndxWTBj5em7DWYOnb4+vZnj8Jnl3gj9LQ46Qz+FuC44TLWUQEs73W6AE8gVX/10m05HDwnVrgPk/AHykBD4XAo6QuXHThQky68fo=; X-YMail-OSG: MLMxqSEVM1nRglpXplvm_b.gce0_KjJC7UEiWxyp1z2V8S4 ifRu4T7EqLh.gTimwXIhTgTBjxHWWZPNE3F9tBviCITBR.Y.GSwrI6qmRinI eaXszSKJ_dVuOXKkrynj89EEVhhmM.PCKMgfuTZJhJ3BfUfP8SvpxxJOUzH_ IggeyXNaLpqSQdEGp3NQkmGVdM3gZzZy7NJIdLfpBh.ObhkXJaG0p8EkcaD. JN03VfZli7CtBzy3vWAgGb1cCdtJXM8mc1DC9O.cF1GYSwj7dzU_CQfsmyPA xTiNMr8QZRT.6vzNwRGjMWVXWlUR7noz4.iUbQ5Q1ymTL.FUSCtRauyoyTWA LGaI2cezbBDO9_3uHkh1TJZrCUqEcy0e76myJojd_jPG3GGrZBS78tl1Ff1x Cm6bSlJ4bpu1M06dixCR5fYZABZYr_.4g32yeD5xvUEhXde9LZe6B.aVS4ag crT2MhMHhAaTtGW1jTDd5KkbMxQ427uKQjUW96SGSZzgH50wJaMYu7GXcRRi S.vBxVvY59iOV19Yv1TAWbXI4cR7jxZRSCVAvzst9IRzORFZUgOmgDZ7ubHR glWpQn0hDei_v3bRD5_qmsNEENg-- Received: from [150.101.221.237] by web162206.mail.bf1.yahoo.com via HTTP; Fri, 14 Feb 2014 19:37:24 PST X-Rocket-MIMEInfo: 002.001, SGksCgoKSSB0aGluayBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gbm90IHNwZWNpZmljYWxseSBjb3VwbGUgYWRkcmVzcyBjb25maWd1cmF0aW9uIG1ldGhvZHMgKFNMQUFDLCBESENQdjYsIHN0YXRpYy9tYW51YWwpIHdpdGggYWRkcmVzcyBnZW5lcmF0aW9uIG1ldGhvZHMgKE1BQyBkZXJpdmVkLCBSRkM0OTQxLCBjcnlwdG9ncmFwaGljYWxseSBnZW5lcmF0ZWQgZXRjLikuIEkgdGhpbmsgd2hhdCBpcyBiZWluZyBkaXNjdXNzZWQgYWJvdXQgYWRkcmVzc2VzIGVxdWFsbHkgYXBwbGllcyByZWdhcmRsZXNzIG9mIHQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <20140214184335.29433.45425.idtracker@ietfa.amsl.com> Message-ID: <1392435444.66015.YahooMailNeo@web162206.mail.bf1.yahoo.com> Date: Fri, 14 Feb 2014 19:37:24 -0800 (PST) From: Mark ZZZ Smith Subject: Re: I-D Action: draft-ietf-6man-ipv6-address-generation-privacy-01.txt To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" In-Reply-To: <20140214184335.29433.45425.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/LgeytgGrMggjDoEr1CxyGmqSA6g Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 15 Feb 2014 03:37:28 -0000 Hi,=0A=0A=0AI think it would be useful to not specifically couple address c= onfiguration methods (SLAAC, DHCPv6, static/manual) with address generation= methods (MAC derived, RFC4941, cryptographically generated etc.). I think = what is being discussed about addresses equally applies regardless of the a= ddress configuration method used to configure the resulting IPv6 address on= an interface.=0A=0ASo, for example, dropping the address configuration met= hod:=0A=0A=0A"Over the years, many interface identifier generation =A0techn= iques have been defined, both standardized and non-standardized:=0A=0A=A0 = =A0 =A0 * =A0IPv4 address=0A=0A=A0 =A0 =A0 * =A0Service port=0A=0A=A0 =A0 = =A0 * =A0Wordy=0A=0A=A0 =A0 =A0 * =A0Low-byte=0A=0A=A0 =A0 =A0 * =A0IEEE 80= 2 48-bit MAC or IEEE EUI-64 identifier=0A=A0 =A0 =A0 =A0 =A0[RFC1972][RFC24= 64]=0A=0A=A0 =A0 =A0 * =A0Cryptographically generated [RFC3972]=0A=0A=A0 = =A0 =A0 * =A0Temporary (also known as "privacy addresses") [RFC4941]=0A=0A= =A0 =A0 =A0 * =A0Constant, semantically opaque (also known as random)=0A=A0= =A0 =A0 =A0 =A0[Microsoft]=0A=0A=A0 =A0 =A0 * =A0Stable, semantically opaq= ue=0A=A0 =A0 =A0 =A0 =A0[I-D.ietf-6man-stable-privacy-addresses]=0A=0A=A0 = =A0 =A0 * =A0IPv4 address and port [RFC4380]"=0A=0ARegards,=0AMark. From nobody Fri Feb 14 23:04:05 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8BDF1A007D for ; Fri, 14 Feb 2014 23:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foYKBrR4KTXV for ; Fri, 14 Feb 2014 23:04:02 -0800 (PST) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id EC9AF1A0079 for ; Fri, 14 Feb 2014 23:04:01 -0800 (PST) Received: from [10.0.1.44] (184-23-158-127.dsl.dynamic.sonic.net [184.23.158.127]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s1F73vO0025046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 14 Feb 2014 23:03:57 -0800 Message-ID: <52FF115C.30001@acm.org> Date: Fri, 14 Feb 2014 23:03:56 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: IETF IPv6 Subject: Fwd: New Version Notification for draft-chakrabarti-nordmark-6man-efficient-nd-05.txt References: <20140214235734.2509.63069.idtracker@ietfa.amsl.com> In-Reply-To: <20140214235734.2509.63069.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140214235734.2509.63069.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;Ao6EVg+W4xGjWLFBJ1f4WQ== M;aveoVg+W4xGjWLFBJ1f4WQ== Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/EjB8mzHVzmfK9lt2xFqiNkALAPU X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 07:04:04 -0000 Samita has already outlined some of the changes we have been making based on the feedback from the list. In addition this version has significant editorial changes based on the feedback, and also more detail for the host and router behavior. It also addresses some additional technical issues that have been raised, notable how it works with VRRP and the routers being a SPoF. Those are handled with a new Registrar Address Option which can be included in RAs. Erik -------- Original Message -------- Subject: New Version Notification for draft-chakrabarti-nordmark-6man-efficient-nd-05.txt Date: Fri, 14 Feb 2014 15:57:34 -0800 From: internet-drafts@ietf.org To: Pascal Thubert , Erik Nordmark , Pascal Thubert , Margaret Wasserman , Samita Chakrabarti , Erik Nordmark , Samita Chakrabarti , Margaret Wasserman A new version of I-D, draft-chakrabarti-nordmark-6man-efficient-nd-05.txt has been successfully submitted by Erik Nordmark and posted to the IETF repository. Name: draft-chakrabarti-nordmark-6man-efficient-nd Revision: 05 Title: IPv6 Neighbor Discovery Optimizations for Wired and Wireless Networks Document date: 2014-02-14 Group: Individual Submission Pages: 35 URL: http://www.ietf.org/internet-drafts/draft-chakrabarti-nordmark-6man-efficient-nd-05.txt Status: https://datatracker.ietf.org/doc/draft-chakrabarti-nordmark-6man-efficient-nd/ Htmlized: http://tools.ietf.org/html/draft-chakrabarti-nordmark-6man-efficient-nd-05 Diff: http://www.ietf.org/rfcdiff?url2=draft-chakrabarti-nordmark-6man-efficient-nd-05 Abstract: IPv6 Neighbor Discovery (RFC 4861 going back to RFC 1970) was defined at a time when link-local multicast was as reliable and with the same network cost (send a packet on a yellow-coax Ethernet) as unicast and where the hosts were assumed to be always on and connected. Since 1996 we've seen a significant change with both an introduction of wireless networks and battery operated devices, which poses significant challenges for the old assumptions. We are also seeing datacenter networks where virtual machines are not always on and connected, and scaling of multicast can be challenging. This specification contains extensions to IPv6 Neighbor Discovery which remove most use of multicast and make sleeping hosts more efficient. The specification includes a default mixed mode where a link can have an arbitrary mix of hosts and/or routers - some implementing legacy Neighbor Discovery and some implementing the optimizations in this specification. The optimizations provide incremental benefits to hosts as soon as the first updated routers are deployed on a link. 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 From nobody Sun Feb 16 11:42:53 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8641A0265 for ; Sun, 16 Feb 2014 11:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.001 X-Spam-Level: * X-Spam-Status: No, score=1.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVVHUGJuhoc1 for ; Sun, 16 Feb 2014 11:42:49 -0800 (PST) Received: from nm46.bullet.mail.ne1.yahoo.com (nm46.bullet.mail.ne1.yahoo.com [98.138.120.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9F21C1A022A for <6man@ietf.org>; Sun, 16 Feb 2014 11:42:48 -0800 (PST) Received: from [127.0.0.1] by nm46.bullet.mail.ne1.yahoo.com with NNFMP; 16 Feb 2014 19:42:46 -0000 Received: from [98.138.101.132] by nm46.bullet.mail.ne1.yahoo.com with NNFMP; 16 Feb 2014 19:39:50 -0000 Received: from [66.196.81.173] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 16 Feb 2014 19:39:50 -0000 Received: from [98.139.212.219] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 16 Feb 2014 19:39:50 -0000 Received: from [127.0.0.1] by omp1028.mail.bf1.yahoo.com with NNFMP; 16 Feb 2014 19:39:50 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 468437.30296.bm@omp1028.mail.bf1.yahoo.com Received: (qmail 94027 invoked by uid 60001); 16 Feb 2014 19:39:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1392579590; bh=EHIJziCxUdyXBPANlOOmDn4Krw8s9t4okw+Aeg18uj4=; 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=ne/vnlVQYoAsmNLSqoEqpLunKTB92vWORPQDeByfmUg7LSEfj2Nz3w/hE3FPo127DoCj6poNonqZplyG3pPhPONXYSqC+yMlbOiQ6vJYfvhGen+v1kR3hTXqw+tCCXtSGBxffvhEcpQf6pz1BvfwP9FYbkOzLnD8EbyW0AGcHaU= 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=xnI7FsRDurUKF5ji+bbiid+kK11MGBKwAy684Ziv/LgJkZIrfhkem78g6cGpc0Ry69yRTTq/3DG8z+/t+U9Xintc64UITVrS7WO2igars7ryAfMbFHa5OZQZkpkWJm9/gTvhsbdTo/lqG0ViG+WpqIi7JqpXTc4fUolcoNOYGoQ=; X-YMail-OSG: m.VJmrsVM1lQgicSWItl0yRgc8zu9k4tkBZIkEuGzAlqTMW 1AmeYcVlhfBs3nySRy8d5nepYok8OQj2i1_4biaRSpFIjh50JUwiP4bnZLLk YdPE3CfuVsB1F25yLKmFjnwDsW2P7G3Xx3ZOGp4Sfrr2IDaIfY5cHtWeidHj 06_K.kmZD5R4jKShssU14BvZpA_W.B_WORdEWTeNjb04Wn84ihLH0W3FdV7A YuEvI4vI3pKgoEbYdXSoO2008dz0CCiW6hp943aSvo_jKSedJQ3qmXDmIpW7 pj9y5.dcoKzgA0ElZrKMzxkb6FCLeW1RtANIxHLaJ6mUumSpfRlhBRSBn9sI uax0QPIYgEBzZIT53o9sx4xMJGVhow7sRhU.HY63kIGnMkotAkhrXyZw8Aic W2BHI06hPWK2N8ExYGJuo3uW0Ft92D92cgjKTO4nisg2KDXXL_iv9o0Y.eAa HgWq805jtPTNPUj41Ju4dzyFB4tGOo3AorQ4M_.yhG6kZoJ6KItvMB3FVQcr _DG6MnB7PmZXAqoWM3MsEpkjNi.Sn4dHTICbTczT2AoVGcka4JD5vacm3aEm LsXDs9whQU76oxfEGMwtzOQCUXacduMn9oFYc Received: from [150.101.221.237] by web162205.mail.bf1.yahoo.com via HTTP; Sun, 16 Feb 2014 11:39:50 PST X-Rocket-MIMEInfo: 002.001, CkhpIEZlcm5hbmRvLAoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20.Cj4gVG86IE1hcmsgWlpaIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1PjsgRmVybmFuZG8gR29udCA8ZmVybmFuZG9AZ29udC5jb20uYXI.OyBPbGUgVHJvYW4gPG90cm9hbkBlbXBsb3llZXMub3JnPgo.IENjOiBUaG9tYXMgTmFydGVuIDxuYXJ0ZW5AdXMuaWJtLmNvbT47IEMuIE0uIEhlYXJkIDxoZWFyZEBwb2JveC5jb20.OyBUaW0gQ2gBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <52F1B8CE.4070803@ericsson.com> <52F1BD1F.2080007@si6networks.com> <52F383A0.7030002@si6networks.com> <52F44A73.3000609@si6networks.com> <86BA587E-A7F8-47B9-AC74-98D3DB9A7E46@employees.org> <52F4DDC7.8070606@si6networks.com> <1391817989.71306.YahooMailNeo@web162204.mail.bf1.yahoo.com> <52F927E0.5080706@gont.com.ar> <1392193724.5329.YahooMailNeo@web162201.mail.bf1.yahoo.com> <52FDDA1B.3060104@si6networks.com> Message-ID: <1392579590.62475.YahooMailNeo@web162205.mail.bf1.yahoo.com> Date: Sun, 16 Feb 2014 11:39:50 -0800 (PST) From: Mark ZZZ Smith Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers To: Fernando Gont , Fernando Gont , Ole Troan In-Reply-To: <52FDDA1B.3060104@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Gsfd2HukipdbuisW03TcKjpVxbo Cc: Thomas Narten , "C. M. Heard" , Tim Chown , "6man@ietf.org" <6man@ietf.org>, Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 16 Feb 2014 19:42:51 -0000 =0AHi Fernando,=0A=0A=0A----- Original Message -----=0A> From: Fernando Gon= t =0A> To: Mark ZZZ Smith ; Fernando Gont ; Ole Troan = =0A> Cc: Thomas Narten ; C. M. Heard ; = Tim Chown ; "6man@ietf.org" <6man@ietf.org>; Suresh Kr= ishnan =0A> Sent: Friday, 14 February 2014 7:= 55 PM=0A> Subject: Re: A problem with RFC 6465's Uniform Format for Extensi= on Headers=0A> =0A> Hi, Mark,=0A> =0A> On 02/12/2014 05:28 AM, Mark ZZZ Smi= th wrote:=0A>>>=A0 Depends on what you mean by end-to-end crypto, and in wh= at=0A>>>=A0 context.=0A>>> =0A>>>=A0 SSL/TLS for say, web servers and mails= ervers, fine.=0A>>> =0A>>>=A0 IPsec for the general case...mmm.. unlikely.= =0A>>> =0A>>>=A0 Is there any plan for solving the authentication of nodes?= Is=0A>>>=A0 everyone expected to get/buy a certificate?=0A>>> =0A>> =0A>>= =A0 Any or all of them. In the latter case, BTNS mode of IPsec (RFC5386)=0A= >>=A0 would probably be better than NSA can have everything(tm) IP because= =0A>>=A0 it shrinks their window to be a MITM.=0A> =0A> Which my result in = "placebo" security: you never know if you've =0A> been=0A> MITM'ed.=A0 :-(= =0A>=A0=0A=0AGiven recent revelations, it is probably better to assume we a= lready have been.=0A=0AI think security is relative, not absolute. BTNS mod= e of IPsec protecting traffic would be much better than nothing protecting = traffic. Even if you are MITM'd, at least the costs of uncovering the traff= ic go up, creating more of a disincentive to MITM unless they have to.=0A= =0A> =0A> =0A>>>>=A0 I think it might be worth remembering that as per the = IETF88=0A>>>>=A0 Plenary, end-to-end encryption is the general direction, a= nd that=0A>>>>=A0 middle boxes less effective/in-effective because of it. S= o=0A>>>>=A0 putting a lot of time and effort into facilitating them might b= e=0A>>>>=A0 wasted effort.=0A>>> =0A>>>=A0 It's a 1-page to 5-page document= (and that's including=0A>>>=A0 bolierplates).=0A>> =0A>>=A0 I'm not saying= to no do it, just that if e.g., somebody like Google,=0A>>=A0 Apple or Mic= rosoft roll out an update that enables crypto on a very=0A>>=A0 popular ser= vice (similar to how within days, millions of iPhones and=0A>>=A0 iPads use= d MPTCP for Siri), the traffic that these middleboxes are=0A>>=A0 inspectin= g might "go dark" or become hidden =0A> "overnight".=0A> =0A> If e.g. TLS i= s enabled, the TCP header information is still in the clear=0A> (unless you= 're *tunneling* over TLS).=0A>=A0=0A>=A0=0A=0A>>=A0 If there is=0A>>=A0 a l= ot of effort involved, it would be wasted if that sort of event=0A>>=A0 hap= pened.=0A> =0A> This shouldn't be "a lot of effort".=0A> =0A> =0A> =0A>>>>= =A0 Yes, it works! Thanks Kristian. However here in Italy 3G carriers=0A>>>= >=A0 filter out TCP options.. so SIRI gives up and stops trying to use=0A>>= >>=A0 mptcp in the long run.=0A>> =0A>>=A0 "Encapsulation of TCP and other = Transport Protocols over UDP" =0A>>=A0 http://tools.ietf.org/html/draft-che= shire-tcp-over-udp-00=0A>> =0A>>=A0 "In fact, TCP options are expected to w= ork more reliably with=0A>>=A0 TCP-over-UDP, because middleboxes will be le= ss able to easily=0A>>=A0 interfere with such options, modifying them, stri= pping them, or=0A>>=A0 dropping packets containing TCP options, as they oft= en dotoday with=0A>>=A0 native TCP=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 packets.=A0 In particular, Multipath=0A>>=A0 TCP-over-UDP is expected t= o work more reliably than native Multipath=0A>>=A0 TCP [RFC6824], because m= iddleboxes that interfere with use of those=0A>>=A0 TCP options will be les= s able to do that when the packets are=0A>>=A0 encapsulated inside UDP."=0A= >> =0A>>=A0 ;-)=0A> =0A> Well, how good this is probably depends on whether= one assumes the=0A> aforementioned middle-box behavior is intentional or n= ot. If it is, then=0A> this is "middle-box unfriendly". If it's not, this i= s =0A> "middle-box=0A> friendly".=0A=0AI think that as it is dropping unkno= wn TCP options, rather than forwarding them, it=A0indicates it is fundament= ally intentional. A middle box "in the customers interests" would default t= o forwarding when it encounters unknown options, field values etc., allowin= g MPTCP to work.=0A=0AIn this specific case, it could be that as Siri uses = 3G as a backup path for MPTCP for Wifi, Italy's 3G carriers might be blocki= ng the MPTCP options to prevent Wifi offload via MPTCP, forcing customers t= o use and therefore pay for 3G bandwidth use even when they don't have to.= =0A=0ACustomers certainly won't like that if they discover it, however the = customers won't necessarily realise that it is the carrier that they're pay= ing that is causing them to have a less reliable and more costly service. H= owever, the people who provide Siri to those customers would be capable of = finding out where the problem is, and may then develop and deploy work-arou= nds to the problem of TCP options being dropped. I don't know if you notice= d, but the authors of that draft are from Apple, who have a very strong inc= entive for Siri to work well for their customers.=0A=0A> FWIW, one would ex= pect this to be an arms race. If this is=0A> *intended middle-box behavior"= , then you'd expect middle-boxes to =0A> become=0A> smarter, and eventually= we'll have TCP-over-UDP-over-* :-)=0A>=A0=0A=0AI agree it will be an arms = race, and I'm confident that the host/application people will eventually wi= n. I think their fundamental desire is network transparency so that they ca= n spend time and effort on better application features, rather than on work= around methods to get the data they want between the application end-point= s.=A0The harder the network makes it for the host/application developers to= add new and useful features, the harder the host/application developers wi= ll push back, with obfuscation being their weapon.=0A=0ARegards,=0AMark. From nobody Sun Feb 16 18:50:17 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256281A032E for ; Sun, 16 Feb 2014 18:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzowo_erWMyw for ; Sun, 16 Feb 2014 18:50:13 -0800 (PST) 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 920361A032B for ; Sun, 16 Feb 2014 18:50:13 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id kx10so14684437pab.35 for ; Sun, 16 Feb 2014 18:50:11 -0800 (PST) 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:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pAI0Dce2OjNHKTUli1Dqy0Jdi9pgWA5orreAwVPQVqY=; b=bfkQY/yX1Zb/Qfg/u8oPPZ/AcgH3G2+XbbP+ZtdTskjqR3NelReV+msT7eE5GmdrkM HeBcUYrbGpVXn/Ld6ruhCcaKTRNUrbUMJQdBx3WOyY4JQn3uxp20fG43o79c1jsQ739Y 6qaMhulVqQjI5kzVtYXMIJXIShiwJFh9eW/rOvBIiHieS6j4p/QuW6s6HgB7zMSAvEv2 AzwqQTi9b6r6IGhL1Vxm/HD2IKYCCE2ajOeDnA39CWVkmxHuB2tb6KVJUhhdBt9jXntY SPefcW1GgG4wQWkTKGaRU67MK+n459Dmk5TZi2fIGEKkZy0+84tHUrlmKSeCo6zqoAUe 6Ynw== X-Received: by 10.66.65.204 with SMTP id z12mr23548043pas.60.1392605411309; Sun, 16 Feb 2014 18:50:11 -0800 (PST) Received: from [192.168.178.23] (22.200.69.111.dynamic.snap.net.nz. [111.69.200.22]) by mx.google.com with ESMTPSA id c7sm40432648pbt.0.2014.02.16.18.50.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Feb 2014 18:50:10 -0800 (PST) Message-ID: <530178E1.6010206@gmail.com> Date: Mon, 17 Feb 2014 15:50:09 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 CC: 6man Subject: Re: I-D Action: draft-ietf-6man-default-iids-00.txt References: <20140124142141.1829.4747.idtracker@ietfa.amsl.com> In-Reply-To: <20140124142141.1829.4747.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/my8AnlGdGth9mHfhWJuPOHpVvaE X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 02:50:15 -0000 Hi, I think this is the right way to close off the EUI-64 debate. Just a couple of small comments: > NOTE: [RFC4291] defines the "Modified EUI-64 format" for Interface > identifiers. Appendix A of [RFC4291] then describes how to transform > an IEEE EUI-64 identifier, or an IEEE 802 48-bit MAC address from > which an EUI-64 identifier is derived, into an interface identifier > in the Modified EUI-64 format. I suggest adding something like [RFC7136] updates RFC 4291 to remove the requirement to use the Modified EUI-64 format. (see http://tools.ietf.org/html/rfc7136#section-5) > Nodes SHOULD NOT employ IPv6 address generation schemes that embed > the underlying hardware address in the Interface Identifier. Namely, > nodes SHOULD NOT generate Interface Identifiers with the schemes > specified in [RFC2464], [RFC2467], and [RFC2470]. Is that list complete? In draft-carpenter-6man-why64 we have quite a list of IPv6-over-foo documents. It would perhaps be better to s/Namely/In particular/. Regards Brian From nobody Mon Feb 17 02:06:13 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1041E1A047B for ; Mon, 17 Feb 2014 02:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1jwmQk-8Cph for ; Mon, 17 Feb 2014 02:06:03 -0800 (PST) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.100]) by ietfa.amsl.com (Postfix) with ESMTP id D5E311A047D for ; Mon, 17 Feb 2014 02:06:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zoho; d=internetdraft.org; h=date:from:to:cc:message-id:in-reply-to:references:subject:mime-version:content-type:user-agent; b=iqMDbm9PcVTqFDF/lZbGPZry1ywGl6EPCUK9VLb28vvBDugJNGc9DVTN+RU8V8egcIZelnC3Ufzn hVKJm7/Ti2rK2B9hHgFEdao5cQLcdp6AtMffy8aOxKMWAkASBvX/5MMceWfd3AzqL2ph5Xuc1iV2 K8Fhfzkvyb5ZL+129P4= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1392631505242756.1810269767932; Mon, 17 Feb 2014 02:05:05 -0800 (PST) Date: Mon, 17 Feb 2014 19:05:05 +0900 From: ek To: "Hemant Singh (shemant)" Message-ID: <1315813580.259590.1392631505190.JavaMail.sas1@[172.29.252.247]> In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89115D182D@xmb-rcd-x06.cisco.com> References: <52D96663.6060005@sonic.net> <52DA0ABA.8030903@acm.org> <52E03BB4.8040309@acm.org> <52E0423A.5070906@acm.org> <01DC3532-C73A-4644-A323-04BE6231AADA@employees.org> <52E9EF2D.9050402@acm.org> <2CFF305E-DE44-4D57-82D3-241196D94610@employees.org> <52ECA6EE.1080201@acm.org> <75B6FA9F576969419E42BECB86CB1B89115D182D@xmb-rcd-x06.cisco.com> Subject: RE: Reducing the battery impact of ND MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Xs7x9q7q3hGsA8rCRYh-O9wwl3E Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG , Andrew Yourtchenko , Erik Nordmark X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 10:06:06 -0000 > If the community is interested in supporting a new ethertype for IPv6 ND, please let me know. I would expedite an I-D from Cisco who has IPR related to the new ethertype. See > > http://www.google.com/patents/US8102854 I haven't read this, but, IMHO, the potential existence of IPR about using a new ethertype for NUD messages is a wonderful reason to *never ever* do this. From nobody Mon Feb 17 05:41:28 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4221A03E1 for ; Mon, 17 Feb 2014 05:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qJpEasKEeFR for ; Mon, 17 Feb 2014 05:41:24 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 91C581A01EA for ; Mon, 17 Feb 2014 05:41:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1118; q=dns/txt; s=iport; t=1392644482; x=1393854082; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hdb5e4aB5luHRqSMmnssiin0SUhEQBfOuZMbCayJd0k=; b=SOF4JYE1ecG/Xq0ract/FjHLJJJIL3HCKhZFOoe2Gyk7WYgnG8z5dVx4 upmyYBIIDpWUd6tqfApjyk8k/T7uMIPKo4cHmXG63Ek7RoT2qBNQ3lNC1 C7KkbVQ8h5LUlZP/yiHvjDj1kGwaVQApMtZW/5MC++i2VApTRfMtMevHm s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAMcQAlOtJXHA/2dsb2JhbABZgwY4V4MCvDYYgQYWdIIlAQEBAwEjEUUMBAIBCBEEAQEDAgYdAwICAjAUAQgIAgQOBQgMh2kIDal5oVoXgSmMcDcxBwaCaTWBFAEDqk+DLYIq X-IronPort-AV: E=Sophos;i="4.95,860,1384300800"; d="scan'208";a="106143890" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by mtv-iport-2.cisco.com with ESMTP; 17 Feb 2014 13:41:20 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1HDfKIl031106 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Feb 2014 13:41:20 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.68]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 07:41:19 -0600 From: "Hemant Singh (shemant)" To: ek Subject: RE: Reducing the battery impact of ND Thread-Topic: Reducing the battery impact of ND Thread-Index: AQHPF8uCi/rGSSFcckK5k2X6Rw6QUJqdO7yAgABDuoCAAA28gIAC6/EAgAGb2ICAF694gP//1Ttw Date: Mon, 17 Feb 2014 13:41:19 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89115E3B8D@xmb-rcd-x06.cisco.com> References: <52D96663.6060005@sonic.net> <52DA0ABA.8030903@acm.org> <52E03BB4.8040309@acm.org> <52E0423A.5070906@acm.org> <01DC3532-C73A-4644-A323-04BE6231AADA@employees.org> <52E9EF2D.9050402@acm.org> <2CFF305E-DE44-4D57-82D3-241196D94610@employees.org> <52ECA6EE.1080201@acm.org> <75B6FA9F576969419E42BECB86CB1B89115D182D@xmb-rcd-x06.cisco.com> <1315813580.259590.1392631505190.JavaMail.sas1@[172.29.252.247]> In-Reply-To: <1315813580.259590.1392631505190.JavaMail.sas1@[172.29.252.247]> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.246.66] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/CbikAl0e3OgHMaT7Gg2IfDc5ddw Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG , Andrew Yourtchenko , Erik Nordmark X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 13:41:26 -0000 Q2lzY28gSVBSIHNob3VsZCBub3QgYmxvY2sgdGhpcyB3b3JrLiAgIFRoZXJlIGFyZSBzZXZlcmFs IGRyYWZ0cyBpbiB0aGUgSUVURiB0aGF0IGFyZSB1bmRlcndheSB3aXRoIElQUiBmcm9tIENpc2Nv IGFuZCBvdGhlciBjb21wYW5pZXMuIA0KDQpIZW1hbnQgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBlayBbbWFpbHRvOmVrQGludGVybmV0ZHJhZnQub3JnXSANClNlbnQ6IE1v bmRheSwgRmVicnVhcnkgMTcsIDIwMTQgNTowNSBBTQ0KVG86IEhlbWFudCBTaW5naCAoc2hlbWFu dCkNCkNjOiBFcmlrIE5vcmRtYXJrOyBXYXJyZW4gS3VtYXJpOyBPbGUgVHJvYW47IDZtYW4gQ2hh aXJzOyA2bWFuIFdHOyBBbmRyZXcgWW91cnRjaGVua28NClN1YmplY3Q6IFJFOiBSZWR1Y2luZyB0 aGUgYmF0dGVyeSBpbXBhY3Qgb2YgTkQNCg0KID4gSWYgdGhlIGNvbW11bml0eSBpcyBpbnRlcmVz dGVkIGluIHN1cHBvcnRpbmcgYSBuZXcgZXRoZXJ0eXBlIGZvciBJUHY2IE5ELCBwbGVhc2UgbGV0 IG1lIGtub3cuICBJIHdvdWxkIGV4cGVkaXRlIGFuIEktRCBmcm9tIENpc2NvIHdobyBoYXMgSVBS IHJlbGF0ZWQgdG8gdGhlIG5ldyBldGhlcnR5cGUuICBTZWUgID4gID4gaHR0cDovL3d3dy5nb29n bGUuY29tL3BhdGVudHMvVVM4MTAyODU0IA0KIA0KSSBoYXZlbid0IHJlYWQgdGhpcywgYnV0LCBJ TUhPLCB0aGUgcG90ZW50aWFsIGV4aXN0ZW5jZSBvZiBJUFIgYWJvdXQgdXNpbmcgYSBuZXcgZXRo ZXJ0eXBlIGZvciBOVUQgbWVzc2FnZXMgaXMgYSB3b25kZXJmdWwgcmVhc29uIHRvICpuZXZlciBl dmVyKiBkbyB0aGlzLg0KDQo= From nobody Mon Feb 17 08:00:40 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809F81A0533 for ; Mon, 17 Feb 2014 08:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJ5d_kePp5Vr for ; Mon, 17 Feb 2014 08:00:37 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id B029C1A0527 for ; Mon, 17 Feb 2014 08:00:35 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s1HG0Kro050615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Feb 2014 16:00:20 GMT (envelope-from joelja@bogus.com) Message-ID: <5302320F.6000000@bogus.com> Date: Mon, 17 Feb 2014 08:00:15 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: "Hemant Singh (shemant)" , ek Subject: Re: Reducing the battery impact of ND References: <52D96663.6060005@sonic.net> <52DA0ABA.8030903@acm.org> <52E03BB4.8040309@acm.org> <52E0423A.5070906@acm.org> <01DC3532-C73A-4644-A323-04BE6231AADA@employees.org> <52E9EF2D.9050402@acm.org> <2CFF305E-DE44-4D57-82D3-241196D94610@employees.org> <52ECA6EE.1080201@acm.org> <75B6FA9F576969419E42BECB86CB1B89115D182D@xmb-rcd-x06.cisco.com> <1315813580.259590.1392631505190.JavaMail.sas1@[172.29.252.247]> <75B6FA9F576969419E42BECB86CB1B89115E3B8D@xmb-rcd-x06.cisco.com> In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89115E3B8D@xmb-rcd-x06.cisco.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cw47LM5eEkCOMoJtCJHewXFrjhJggvgX0" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 17 Feb 2014 16:00:21 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/UKk6qWP6ZP8hZmQHeHSJ9Jcfh1k Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Andrew Yourtchenko , 6man WG , Erik Nordmark X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 16:00:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cw47LM5eEkCOMoJtCJHewXFrjhJggvgX0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2/17/14, 5:41 AM, Hemant Singh (shemant) wrote: > Cisco IPR should not block this work. There are several drafts in the= IETF that are underway with IPR from Cisco and other companies.=20 The participants address the question of IPR on per-draft basis. > Hemant=20 >=20 > -----Original Message----- > From: ek [mailto:ek@internetdraft.org]=20 > Sent: Monday, February 17, 2014 5:05 AM > To: Hemant Singh (shemant) > Cc: Erik Nordmark; Warren Kumari; Ole Troan; 6man Chairs; 6man WG; Andr= ew Yourtchenko > Subject: RE: Reducing the battery impact of ND >=20 > > If the community is interested in supporting a new ethertype for IPv= 6 ND, please let me know. I would expedite an I-D from Cisco who has IPR= related to the new ethertype. See > > http://www.google.com/patents/U= S8102854=20 > =20 > I haven't read this, but, IMHO, the potential existence of IPR about us= ing a new ethertype for NUD messages is a wonderful reason to *never ever= * do this. >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 --cw47LM5eEkCOMoJtCJHewXFrjhJggvgX0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMCMg8ACgkQ8AA1q7Z/VrK6YACdGKu5T6LJ+eeZoJ1EvNBhSIHj xR4An1hfPB2QHvOu+JI1K6kmULjyqGPR =cE64 -----END PGP SIGNATURE----- --cw47LM5eEkCOMoJtCJHewXFrjhJggvgX0-- From nobody Mon Feb 17 08:22:57 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F581A0512 for ; Mon, 17 Feb 2014 08:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6AQXmGkBqAv for ; Mon, 17 Feb 2014 08:22:53 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 10E161A03FC for ; Mon, 17 Feb 2014 08:22:52 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id k14so2390069wgh.11 for ; Mon, 17 Feb 2014 08:22:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TuMhCqLHiXdQntcDevgMO2daCdLSLRAtHElhcSAe8L8=; b=QD/mQ1ngznrctKc568l1TtkYgtTiyA0oCgXgDEtCcHbXFc/tq29feCVUmr6fjP4zSJ aSQNZ7P7TdTDQR5fR8H5jllrCkVH6vZHqDi1Ka0higc6UWni7VTd0SkCXJeEW1IWMg77 U3K2TJYiv5qBchTEfRtAGOytYVTPxv91WlwSzvmbfql9gdEZp9Aayo/yva9YQFiYE2pv glEPWMjGCYrF0v+6IrSdJF0nslPytEQfTWMiTHPLnY8zELlGTSkQSHKsCppDJg5mVTgU kUSKiDUPp4+zif6DzPm1Qzk6IRcHbNdK3w6O68yIqgGrqtzwSiAC/WCW3t9Ex18YI+qw GeRQ== X-Gm-Message-State: ALoCoQknpkBjssFVjjh82s3G43Dj+1ucUtj2JOyE+F0VBA040+0KObUKTGQaUP4aeICXopK9dZLp MIME-Version: 1.0 X-Received: by 10.180.98.35 with SMTP id ef3mr13937979wib.39.1392654159977; Mon, 17 Feb 2014 08:22:39 -0800 (PST) Received: by 10.194.54.167 with HTTP; Mon, 17 Feb 2014 08:22:39 -0800 (PST) X-Originating-IP: [98.244.98.35] In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89115E3B8D@xmb-rcd-x06.cisco.com> References: <52D96663.6060005@sonic.net> <52DA0ABA.8030903@acm.org> <52E03BB4.8040309@acm.org> <52E0423A.5070906@acm.org> <01DC3532-C73A-4644-A323-04BE6231AADA@employees.org> <52E9EF2D.9050402@acm.org> <2CFF305E-DE44-4D57-82D3-241196D94610@employees.org> <52ECA6EE.1080201@acm.org> <75B6FA9F576969419E42BECB86CB1B89115D182D@xmb-rcd-x06.cisco.com> <1315813580.259590.1392631505190.JavaMail.sas1@172.29.252.247> <75B6FA9F576969419E42BECB86CB1B89115E3B8D@xmb-rcd-x06.cisco.com> Date: Mon, 17 Feb 2014 11:22:39 -0500 Message-ID: Subject: Re: Reducing the battery impact of ND From: Warren Kumari To: "Hemant Singh (shemant)" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/akKY0vlbXlXcTDaoIzjYqBE2Xzc Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG , Andrew Yourtchenko , Erik Nordmark X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 16:22:55 -0000 On Mon, Feb 17, 2014 at 8:41 AM, Hemant Singh (shemant) wrote: > Cisco IPR should not block this work. There are several drafts in the IETF that are underway with IPR from Cisco and other companies. Block? No. Make people concerned / less likely to implement? Yes. > > Hemant > > -----Original Message----- > From: ek [mailto:ek@internetdraft.org] > Sent: Monday, February 17, 2014 5:05 AM > To: Hemant Singh (shemant) > Cc: Erik Nordmark; Warren Kumari; Ole Troan; 6man Chairs; 6man WG; Andrew Yourtchenko > Subject: RE: Reducing the battery impact of ND > > > If the community is interested in supporting a new ethertype for IPv6 ND, please let me know. I would expedite an I-D from Cisco who has IPR related to the new ethertype. See > > http://www.google.com/patents/US8102854 > > I haven't read this, but, IMHO, the potential existence of IPR about using a new ethertype for NUD messages is a wonderful reason to *never ever* do this. > From nobody Mon Feb 17 09:17:41 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAEC21A00FE for ; Mon, 17 Feb 2014 09:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQ4P3UehQEMo for ; Mon, 17 Feb 2014 09:17:36 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBEF1A04F0 for ; Mon, 17 Feb 2014 09:17:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=918; q=dns/txt; s=iport; t=1392657454; x=1393867054; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SH453afbVeYml0/c5MnrhhzmX1iZ+DMQehEceXFcqj4=; b=Sdg34To+iuq0qyM8P3pNaHiN6vnF96T9zaSz1F3IAzk3Jdb8wQqfEpTL qbOYkwKoItE5EbeIMsxdX1MtpzK5jm9RdfqW4KfQGOJKGmeIHCTEi9Uw+ aTECgdX2LypwiQaFSGEkpxXFx8T/m3JVe5brfnyE2fj6Av2V3r5FUge1Q 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFACVDAlOtJXHA/2dsb2JhbABZgwaBD788gR8WdIIlAQEBBDo/DAQCAQgRBAEBCxQJBzIUCQgCBA4FCId9y3MXjhk3MQcGgx6BFAEDqk+DLYIq X-IronPort-AV: E=Sophos;i="4.95,861,1384300800"; d="scan'208";a="304630849" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 17 Feb 2014 17:17:31 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1HHHV5V004933 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Feb 2014 17:17:31 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.112]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 11:17:30 -0600 From: "Hemant Singh (shemant)" To: Warren Kumari Subject: RE: Reducing the battery impact of ND Thread-Topic: Reducing the battery impact of ND Thread-Index: AQHPF8uCi/rGSSFcckK5k2X6Rw6QUJqdO7yAgABDuoCAAA28gIAC6/EAgAGb2ICAF694gP//1TtwgACUQ4D//6k9MA== Date: Mon, 17 Feb 2014 17:17:30 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89115E71F2@xmb-aln-x06.cisco.com> References: <52D96663.6060005@sonic.net> <52DA0ABA.8030903@acm.org> <52E03BB4.8040309@acm.org> <52E0423A.5070906@acm.org> <01DC3532-C73A-4644-A323-04BE6231AADA@employees.org> <52E9EF2D.9050402@acm.org> <2CFF305E-DE44-4D57-82D3-241196D94610@employees.org> <52ECA6EE.1080201@acm.org> <75B6FA9F576969419E42BECB86CB1B89115D182D@xmb-rcd-x06.cisco.com> <1315813580.259590.1392631505190.JavaMail.sas1@172.29.252.247> <75B6FA9F576969419E42BECB86CB1B89115E3B8D@xmb-rcd-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.71.141] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/gwh-rc4EiM5Of6T4wgIwDn19wyg Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG , Andrew Yourtchenko , Erik Nordmark X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 17:17:39 -0000 -----Original Message----- From: Warren Kumari [mailto:warren@kumari.net]=20 Sent: Monday, February 17, 2014 11:23 AM To: Hemant Singh (shemant) Cc: ek; Erik Nordmark; Ole Troan; 6man Chairs; 6man WG; Andrew Yourtchenko Subject: Re: Reducing the battery impact of ND >Block? No. Make people concerned / less likely to implement? Yes. Do not disagree with you. I did outline uses cases for a new ethertype for= ND for routers that are forwarding several hundred Gig pps that would bene= fit filtering ND packets for various needs some of which are filtering ND p= ackets of a scan attack, especially when the attacker is smart to change th= e source of each subsequent packet the scan sends. Switches too benefit fo= r the same scan attack. Other uses are for a machine that implements ND P= roxy to sniff all ND mcast and unicast packets. Granted ND Proxy is an Ex= perimental RFC. Hemant From nobody Mon Feb 17 14:18:59 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170E01A02AD for ; Mon, 17 Feb 2014 14:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.849 X-Spam-Level: X-Spam-Status: No, score=-0.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tw2_fnvnxCjG for ; Mon, 17 Feb 2014 14:18:55 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C6EA01A02B8 for <6man@ietf.org>; Mon, 17 Feb 2014 14:18:54 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id p9so11712416lbv.34 for <6man@ietf.org>; Mon, 17 Feb 2014 14:18:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=sHc2qMGpUd/9OX1XUV2mMOeFXj3yrpQtDht3VKdb9UU=; b=SHKQEa8v7qXnuqnRqlfbHLC5fNi/rGocwGmqBwJqWW81qjmtqACAT8OqM6HRVCBCEt OnazPPVvTP44h6CJpPhq0pWiR9nNrMjn8RcZqHDodkOHELw/PN5ce/ueamNtbYA9Q/oY XdVytr0jwKwBlyhG3xcPgO1PTnnSDyGUTEJ/XlK9T5YQ+evPWNRBDRv9hN/GixN2G181 Bw+Z53zwB1jKjxTq5Z1Ab7VCz0aUsJ7JF302YcjiFcUgGwSkh66qBq6DBnflMXzyruAy lyNtD0ghdH6yuld7tbyINmISMuJqFMBR2Le1gl24ddCGNgTpN2qDcTIojfbeESRFmITw YLVA== MIME-Version: 1.0 X-Received: by 10.112.45.108 with SMTP id l12mr18317085lbm.21.1392675531002; Mon, 17 Feb 2014 14:18:51 -0800 (PST) Received: by 10.114.170.195 with HTTP; Mon, 17 Feb 2014 14:18:50 -0800 (PST) In-Reply-To: References: <20140210213947.14657.20184.idtracker@ietfa.amsl.com> Date: Mon, 17 Feb 2014 16:18:50 -0600 Message-ID: Subject: Re: New Version Notification for draft-sarikaya-6man-next-hop-ra-00.txt From: Behcet Sarikaya To: =?ISO-8859-1?Q?Dan_L=FCdtke?= Content-Type: multipart/alternative; boundary=001a1134bfc850163304f2a18aa3 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/-qK4bqIytFghB-xUmVqurwaC-A0 Cc: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 22:18:58 -0000 --001a1134bfc850163304f2a18aa3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Dan, Thanks for your comments. My replies inline. I have done the edits but not able to submit it, I will submit Rev 01 as soon as the submissions open up. Regards, Behcet On Fri, Feb 14, 2014 at 11:35 AM, Dan L=FCdtke wrote: > Hi, > > I have very mixed feelings regarding this draft and I have not yet > decided whether it is me or the draft :) > > I just throw my first thoughts in. I might get more verbose later or > next week. Just pick up what you think is helpful and maybe improve > the draft or help me understand why some of the options and fields the > way they are. > > The Route Prefix option from section 7 has a field called Metric. It > is "only" 3 bit long. How was this value chosen? Why not something > that fits perfectly into a more standard type like uint8_t or > uint16_t? And why not the usual preference which is 2 bits wide and > allows to assign low/medium/high/reserved values? Did I miss the > reasoning for the field's width in the preceding text? > > Right. Changed to 8-bit field. > In section 10 the field "prefix" is said to be 16 octets or less in > length. Please make clear that the size MUST always be a multiple of > 16 octets. Please do not specify a field containing a prefix that is > smaller than sizeof(struct in6_addr). We developers will eventually > fill the field using inet_pton() and the last thing we want to do is > to apply bit-magic and/or variable length voodoo. I am sure you have > thought about that it is just the text that is a bit misleading here. > > As also defined in other documents, prefix length field indicates the number of valid leading bits in the prefix. You can use 16 octets for the prefix but the bits in the prefix after the prefix length must be set to zero. I hope it is clear. All options, except the modified Route Prefix option, have a bad > alignment. Starting an IPv6 address or prefix at the 3rd octet of an > option is probably not the best idea. If possible use multiples of 4 > or better 8 octets as starting point. Just one example: Section 13 > Figure 7 could be re-aligned without wasting anything: > > > BAD: > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Next Hop Address ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > + ... + > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | Source Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > + ... + > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | Prefix Length |Resvd|Prf|Metric| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Route Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Prefix (Variable Length) | > . . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > GOOD: > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Prefix Length |Resvd|Prf|Metr.| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Route Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > + + > + Next Hop Address + > + + > + + > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > + + > + Source Address + > + + > + + > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Prefix (Variable Length) | > . . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Despite these formal objections I am still in the process of > understanding how the proposed solution would work in the field. The > Next Hop Address option for example can be used alone. Is this right? > And if so, why would I want this? And to what prefixes does the option > apply? How is this different from a default gateway? > > Normally, no. You want to use it as in Section 11, 12 or 13. In Section 14 you use MUST. This will probably lead to discussion. I > don't think a MUST is required there. SHOULD or MAY is enough, since > these are only considerations. MUST is always something an implementer > gets a headache from :) > > OK > I also have the feeling that consuming 7 numbers from the registry for > new options is a bit too greedy. Do you see any way to reduce the > consumption of this very limited resource? I think it would help > supporting the draft a lot. > > We can consider combinations rather than Sections 8, 9 and 10. > > The usual nitpicking: > Section 4: "eroor" -> "error" > Section 5: "document.The" -> document.[WHITESPACE]The" > Section 7: Figure 1: Metric is too long. It breaks the figure. Maybe > call it "Mtr." in the figure. > Section 7: Field Definition: There is a colon (:) missing after the > first "Metric". Same in Section 11 Figure 5, Section 12 Figure 6 and > Section 13 Figure 7. > Section 8: Figure 2: It is unclear how long the last field is. This is > _very_ confusing for everybody implementing the draft. > Section 9: Figure 3: It is unclear how long the last field is. Same as > above. > > > Done all of these. > Hope that helps and have a nice weekend! > > Dan > > -- > Dan Luedtke > http://www.danrl.de > --001a1134bfc850163304f2a18aa3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dan,

Thanks for your c= omments.

My replies inline.
I have done the edit= s but not able to submit it, I will submit Rev 01 as soon as the submission= s open up.

Regards,

Behcet


On Fri, Feb 14, 2014 at 11:35 AM, D= an L=FCdtke <maildanrl@gmail.com> wrote:
Hi,

I have very mixed feelings regarding this draft and I have not yet
decided whether it is me or the draft :)

I just throw my first thoughts in. I might get more verbose later or
next week. Just pick up what you think is helpful and maybe improve
the draft or help me understand why some of the options and fields the
way they are.

The Route Prefix option from section 7 has a field called Metric. It
is "only" 3 bit long. How was this value chosen? Why not somethin= g
that fits perfectly into a more standard type like uint8_t or
uint16_t? And why not the usual preference which is 2 bits wide and
allows to assign low/medium/high/reserved values? Did I miss the
reasoning for the field's width in the preceding text?


Right. Changed to 8-bit field.
In section 10 the field "prefix" is said to be 16 octets or less = in
length. Please make clear that the size MUST always be a multiple of
16 octets. Please do not specify a field containing a prefix that is
smaller than sizeof(struct in6_addr). We developers will eventually
fill the field using inet_pton() and the last thing we want to do is
to apply bit-magic and/or variable length voodoo. I am sure you have
thought about that it is just the text that is a bit misleading here.

=A0
As also defined in other documents,= prefix length field indicates the number of valid leading bits in the pref= ix. You can use 16 octets for the prefix but the bits in the prefix after t= he prefix length must be set to zero.

I hope it is clear.

All options, except the modified Route Prefix option, have a bad
alignment. Starting an IPv6 address or prefix at the 3rd octet of an
option is probably not the best idea. If possible use multiples of 4
or better 8 octets as starting point. Just one example: Section 13
Figure 7 could be re-aligned without wasting anything:


BAD:
=A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3
=A0 =A0 =A0 =A00 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
=A0 =A0 =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
=A0 =A0 =A0 | =A0 =A0 Type =A0 =A0 =A0| =A0 =A0Length =A0 =A0 | =A0 =A0Next= Hop Address ... =A0 =A0 =A0 |
=A0 =A0 =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
=A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0... =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+
=A0 =A0 =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
=A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ... =A0 =A0 =A0 =A0 =A0 | =A0= =A0 =A0 =A0Source Address =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
=A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0... =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+
=A0 =A0 =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
=A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ... =A0 =A0 =A0 =A0 =A0 | Pre= fix Length |Resvd|Prf|Metric|
=A0 =A0 =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
=A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Route Lifetime= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
=A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Prefix (Variable Length) = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 . =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 .
=A0 =A0 =A0 . =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 .
=A0 =A0 =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+

GOOD:
=A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3
=A0 =A0 =A0 =A00 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
=A0 =A0 =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
=A0 =A0 =A0 | =A0 =A0 Type =A0 =A0 =A0| =A0 =A0Length =A0 =A0 | Prefix Leng= th |Resvd|Prf|Metr.|
=A0 =A0 =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
=A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Route Lifetime= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
=A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +
=A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Next Hop Addre= ss =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +
=A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +
=A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +
=A0 =A0 =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
=A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +
=A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Source Address= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +
=A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +
=A0 =A0 =A0 + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +
=A0 =A0 =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+
=A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Prefix (Variable Length) = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 . =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 .
=A0 =A0 =A0 . =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 .
=A0 =A0 =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+


Despite these formal objections I am still in the process of
understanding how the proposed solution would work in the field. The
Next Hop Address option for example can be used alone. Is this right?
And if so, why would I want this? And to what prefixes does the option
apply? How is this different from a default gateway?

Normally, no. You want to use it as in Section=A0 11,= 12 or 13.

In Section 14 you use MUST. This will probably lead to discussion. I
don't think a MUST is required there. SHOULD or MAY is enough, since these are only considerations. MUST is always something an implementer
gets a headache from :)

OK
=A0
I also have the feeling that consuming 7 numbers from the registry for
new options is a bit too greedy. Do you see any way to reduce the
consumption of this very limited resource? I think it would help
supporting the draft a lot.

We can consider combinations rather than Sections 8, = 9 and 10.
=A0

The usual nitpicking:
Section 4: "eroor" -> "error"
Section 5: "document.The" -> document.[WHITESPACE]The" Section 7: Figure 1: Metric is too long. It breaks the figure. Maybe
call it "Mtr." in the figure.
Section 7: Field Definition: There is a colon (:) missing after the
first "Metric". Same in Section 11 Figure 5, Section 12 Figure 6 = and
Section 13 Figure 7.
Section 8: Figure 2: It is unclear how long the last field is. This is
_very_ confusing for everybody implementing the draft.
Section 9: Figure 3: It is unclear how long the last field is. Same as abov= e.


Done all of these.
=A0
Hope that helps and have a nice weekend!

Dan

--
Dan Luedtke
http://www.danrl.de

--001a1134bfc850163304f2a18aa3-- From nobody Tue Feb 18 02:02:16 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8681A0651 for ; Tue, 18 Feb 2014 02:02:13 -0800 (PST) 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=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwODrfopYCJR for ; Tue, 18 Feb 2014 02:02:09 -0800 (PST) Received: from olfflo.fourcot.fr (fourcot.fr [IPv6:2001:4b98:dc0:41:216:3eff:fe52:be3b]) by ietfa.amsl.com (Postfix) with ESMTP id 60C071A064B for <6man@ietf.org>; Tue, 18 Feb 2014 02:02:09 -0800 (PST) Received: from reglisse.fourcot.fr (dud31.inf.tu-dresden.de [141.76.46.31]) (Authenticated sender: reglisse) by olfflo.fourcot.fr (Postfix) with ESMTPSA id AB8932DFBD for <6man@ietf.org>; Tue, 18 Feb 2014 11:02:05 +0100 (CET) Received: from [IPv6:::1] (localhost [IPv6:::1]) by reglisse.fourcot.fr (Postfix) with ESMTPS id 4EFDB808FF5 for <6man@ietf.org>; Tue, 18 Feb 2014 11:02:05 +0100 (CET) Message-ID: <53032F9D.50203@flo.fourcot.fr> Date: Tue, 18 Feb 2014 11:02:05 +0100 From: Florent Fourcot User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: 6man@ietf.org Subject: Status of the "u" bit for privacy extensions Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/nrvrPxB6wE2dIZG6-b7P7hHL0j4 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 10:02:13 -0000 Hello, the RFC 7136 has removed/clarify the significance of bits in interface identifier for future iids generation, but it does not include any reference to some current iids generation. For example, the RFC 4941 asks to set the bit 6 to zero: http://tools.ietf.org/search/rfc4941#section-3.2.1 Should current implementations following this rule to be updated? What is the current rule for this? Regards, -- Florent. From nobody Tue Feb 18 05:32:01 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015E51A0667 for ; Tue, 18 Feb 2014 05:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eD9Fudw2RSGs for ; Tue, 18 Feb 2014 05:31:50 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3A31A04C8 for <6man@ietf.org>; Tue, 18 Feb 2014 05:31:47 -0800 (PST) Received: from [2001:5c0:1400:a::12e3] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WFklz-00043G-8c; Tue, 18 Feb 2014 14:31:43 +0100 Message-ID: <53035F12.6090208@si6networks.com> Date: Tue, 18 Feb 2014 10:24:34 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Florent Fourcot , 6man@ietf.org Subject: Re: Status of the "u" bit for privacy extensions References: <53032F9D.50203@flo.fourcot.fr> In-Reply-To: <53032F9D.50203@flo.fourcot.fr> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/nIsckYQZx1YUwmJ1ehANAkBgHBI X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 13:31:55 -0000 Hi, Florent, On 02/18/2014 07:02 AM, Florent Fourcot wrote: > > the RFC 7136 has removed/clarify the significance of bits in interface > identifier for future iids generation, but it does not include any > reference to some current iids generation. > > For example, the RFC 4941 asks to set the bit 6 to zero: > http://tools.ietf.org/search/rfc4941#section-3.2.1 > > Should current implementations following this rule to be updated? What is > the current rule for this? Strictly speaking, I'd say that, since RFC4941 has not been updated in this respect, if you comply with RFC4941, you should use the old semantics. That said, in the light of RFC7136, it would probably make sense to use the semantics in RFC7136. -- that's what we did in draft-ietf-6man-stable-privacy-addresses, for instance. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 18 06:07:32 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F771A01D4 for ; Tue, 18 Feb 2014 06:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZ0iBMLDl4k9 for ; Tue, 18 Feb 2014 06:07:26 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 881331A01C2 for ; Tue, 18 Feb 2014 06:07:26 -0800 (PST) Received: from [2001:5c0:1400:a::12e3] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WFlKV-0004xw-19; Tue, 18 Feb 2014 15:07:23 +0100 Message-ID: <53036867.10808@gont.com.ar> Date: Tue, 18 Feb 2014 11:04:23 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: I-D Action: draft-ietf-6man-default-iids-00.txt References: <20140124142141.1829.4747.idtracker@ietfa.amsl.com> <530178E1.6010206@gmail.com> In-Reply-To: <530178E1.6010206@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/VYcaB0PDS0YlUYIgEPBMSNzw8zs Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 14:07:30 -0000 Hi, Brian, Thanks so much for your feedback! -- Please find my comments in-line... On 02/16/2014 11:50 PM, Brian E Carpenter wrote: > Hi, > > I think this is the right way to close off the EUI-64 debate. > Just a couple of small comments: > >> NOTE: [RFC4291] defines the "Modified EUI-64 format" for Interface >> identifiers. Appendix A of [RFC4291] then describes how to transform >> an IEEE EUI-64 identifier, or an IEEE 802 48-bit MAC address from >> which an EUI-64 identifier is derived, into an interface identifier >> in the Modified EUI-64 format. > > I suggest adding something like > > [RFC7136] updates RFC 4291 to remove the requirement to use the > Modified EUI-64 format. Will do (assuming no one opposes). > (see http://tools.ietf.org/html/rfc7136#section-5) > >> Nodes SHOULD NOT employ IPv6 address generation schemes that embed >> the underlying hardware address in the Interface Identifier. Namely, >> nodes SHOULD NOT generate Interface Identifiers with the schemes >> specified in [RFC2464], [RFC2467], and [RFC2470]. > > Is that list complete? In draft-carpenter-6man-why64 we have > quite a list of IPv6-over-foo documents. It would perhaps be > better to s/Namely/In particular/. The list might not be complete, since (so far) we haven't done an exhaustive list of "IPv6 over foo" documents. That said, I think that all such RFCs should be explicitly identified/listed, since they should also be included in the "Updates: .." tag/metadata. Thoughts? Thanks! 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 nobody Tue Feb 18 10:03:00 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76671A067C; Tue, 18 Feb 2014 10:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLuBoly6wYwH; Tue, 18 Feb 2014 10:02:56 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACE11A024B; Tue, 18 Feb 2014 10:02:56 -0800 (PST) Received: from [2001:5c0:1400:a::12e3] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WFp0M-0003aC-TK; Tue, 18 Feb 2014 19:02:51 +0100 Message-ID: <53039F2E.2060209@si6networks.com> Date: Tue, 18 Feb 2014 14:58:06 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mark ZZZ Smith , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Subject: Re: I-D Action: draft-ietf-6man-ipv6-address-generation-privacy-01.txt References: <20140214184335.29433.45425.idtracker@ietfa.amsl.com> <1392435444.66015.YahooMailNeo@web162206.mail.bf1.yahoo.com> In-Reply-To: <1392435444.66015.YahooMailNeo@web162206.mail.bf1.yahoo.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/-DcEFnUw4E2fArJLRSjkCYgoJ60 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 18:02:59 -0000 On 02/15/2014 12:37 AM, Mark ZZZ Smith wrote: > > I think it would be useful to not specifically couple address > configuration methods (SLAAC, DHCPv6, static/manual) with address > generation methods (MAC derived, RFC4941, cryptographically generated > etc.). I think what is being discussed about addresses equally > applies regardless of the address configuration method used to > configure the resulting IPv6 address on an interface. Makes sense -- although for the most part, they do seem to be coupled in practice. e.g., how do you do CGAs with DHCPv6, etc.? It seems to me that while there's a distinction between the mechanism used for address configuration and the resulting IID, for most cases there's a 1 to 1 mapping... and it's valuable how such IIDs are typically generated. Thoughts? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 18 11:06:33 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAFA1A03ED for ; Tue, 18 Feb 2014 11:06:30 -0800 (PST) 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=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewZctNJ7f6bm for ; Tue, 18 Feb 2014 11:06:28 -0800 (PST) Received: from olfflo.fourcot.fr (fourcot.fr [IPv6:2001:4b98:dc0:41:216:3eff:fe52:be3b]) by ietfa.amsl.com (Postfix) with ESMTP id 3442A1A0167 for <6man@ietf.org>; Tue, 18 Feb 2014 11:06:27 -0800 (PST) Received: from reglisse.fourcot.fr (unknown [IPv6:2001:470:51a3:666::1]) (Authenticated sender: reglisse) by olfflo.fourcot.fr (Postfix) with ESMTPSA id 14D962DF2B; Tue, 18 Feb 2014 20:06:24 +0100 (CET) Received: from [IPv6:::1] (localhost [IPv6:::1]) by reglisse.fourcot.fr (Postfix) with ESMTPS id EBF8F80BC9A; Tue, 18 Feb 2014 20:06:22 +0100 (CET) Message-ID: <5303AF2E.3090701@flo.fourcot.fr> Date: Tue, 18 Feb 2014 20:06:22 +0100 From: Florent Fourcot User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: Fernando Gont Subject: Re: Status of the "u" bit for privacy extensions References: <53032F9D.50203@flo.fourcot.fr> <53035F12.6090208@si6networks.com> In-Reply-To: <53035F12.6090208@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/VcCodgnDAAtNc-Jlequr4BhUKkE Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 19:06:30 -0000 >> Should current implementations following this rule to be updated? What is >> the current rule for this? > > Strictly speaking, I'd say that, since RFC4941 has not been updated in > this respect, if you comply with RFC4941, you should use the old semantics. > > That said, in the light of RFC7136, it would probably make sense to use > the semantics in RFC7136. > Thanks Fernando. I'm afraid, it will probably not enough convincing for Linux kernel developers to change the current behaviour. Regards, -- Florent. From nobody Tue Feb 18 13:22:37 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04231A026A for ; Tue, 18 Feb 2014 13:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhu-X7WKYPZM for ; Tue, 18 Feb 2014 13:22:29 -0800 (PST) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id EE7331A0239 for <6man@ietf.org>; Tue, 18 Feb 2014 13:22:28 -0800 (PST) Received: by mail-pb0-f53.google.com with SMTP id md12so17244459pbc.40 for <6man@ietf.org>; Tue, 18 Feb 2014 13:22:25 -0800 (PST) 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=H1J5xqE1GYCXYkupZczg0Inx7Tvujq52ZbNWAZRsBwg=; b=hqo+DBGAjYyph0y1q5sE/gwYhvd5oMQLwEM6I9mzh1TbHchLTQZRJUQJa3/NvfX97Z ZGRIuOQsVItf5Y4NydK9H+DqqQVPYh45pxPAkR/3gZbWWF5fraM73NzFnRmbfuobsriC bxOmH2b9MRogt3yPv+GjSWMp94bXnCUxK15ROv//qQEyPP40bKWjRHlp6VZ8rALbLwr6 vO0AquCmehQMDFUwHmmQl2UqqcTGzYJIWQY+oBvA7iAvz3wt7L+NFR9RDViRFjEKcuUF JFs/BHCstwxzW05sIURz3SwkghUS8+NDPni5ZdOJWXgi5ljaHK2UsLh6SbgUMeI0RyuO razg== X-Received: by 10.67.5.7 with SMTP id ci7mr35101928pad.99.1392758545119; Tue, 18 Feb 2014 13:22:25 -0800 (PST) Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id rb6sm59098223pbb.41.2014.02.18.13.22.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Feb 2014 13:22:24 -0800 (PST) Message-ID: <5303CF15.5030701@gmail.com> Date: Wed, 19 Feb 2014 10:22:29 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Florent Fourcot Subject: Re: Status of the "u" bit for privacy extensions References: <53032F9D.50203@flo.fourcot.fr> <53035F12.6090208@si6networks.com> <5303AF2E.3090701@flo.fourcot.fr> In-Reply-To: <5303AF2E.3090701@flo.fourcot.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/cRVDh9B18wHmjaggvd0KurXK2pQ Cc: Fernando Gont , 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 21:22:32 -0000 On 19/02/2014 08:06, Florent Fourcot wrote: >>> Should current implementations following this rule to be updated? What is >>> the current rule for this? >> Strictly speaking, I'd say that, since RFC4941 has not been updated in >> this respect, if you comply with RFC4941, you should use the old semantics. >> > >> That said, in the light of RFC7136, it would probably make sense to use >> the semantics in RFC7136. >> > > > Thanks Fernando. I'm afraid, it will probably not enough convincing for > Linux kernel developers to change the current behaviour. I don't see a problem. We tried to be careful in RFC7136 not to break or even theoretically invalidate any current code. The document that would ask for a change is draft-ietf-6man-default-iids, if approved. But even so, it would not break any running code. (Personal comment: breaking running code would be a really silly thing for the IETF to do at this stage in the life of IPv6.) Brian From nobody Tue Feb 18 13:26:50 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9321A030D for ; Tue, 18 Feb 2014 13:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwkFR5W26Y-u for ; Tue, 18 Feb 2014 13:26:47 -0800 (PST) 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 5D5251A0081 for ; Tue, 18 Feb 2014 13:26:47 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id md12so17258719pbc.16 for ; Tue, 18 Feb 2014 13:26:44 -0800 (PST) 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=wWN9OjNDavrHZYwJEZO/THZeZkeDJvd0M+8Jv8t2mTU=; b=o2gN77RwloVO2w8f5yDKjsaJPpJ3WOA61Ps/svAKgNBu4s4TEuHLS01YAkftmJpxeq e51nroNbOAhNOzpt6srMM8terk1bhmE53E+hvo9atddXpxEuBWnzwmnypiIKWgm9+woI BuKulfQMTdKgGNERBZweNl7xQSD0u9d6xWc/B4zC0py/KPJD8Ih1hMNv90Ato5bFTryk MhJFEO88B780To1dWcIZ9qAhX5R+8NI3E87TJ43UboRAZOgXgKeGbdPhD6Calqh/a3Rg f0S0nw9ZHin+JnmWFlt1q3aav5doDzUvR7gQ00SJzPsnvXTJz2hBWQEvTJ31ciMuBV7q gTZQ== X-Received: by 10.66.139.100 with SMTP id qx4mr13023524pab.141.1392758804436; Tue, 18 Feb 2014 13:26:44 -0800 (PST) Received: from [172.24.31.170] (wireless-nat-1.auckland.ac.nz. [130.216.30.112]) by mx.google.com with ESMTPSA id f5sm150344936pat.11.2014.02.18.13.26.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Feb 2014 13:26:43 -0800 (PST) Message-ID: <5303D017.4070304@gmail.com> Date: Wed, 19 Feb 2014 10:26:47 +1300 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: I-D Action: draft-ietf-6man-default-iids-00.txt References: <20140124142141.1829.4747.idtracker@ietfa.amsl.com> <530178E1.6010206@gmail.com> <53036867.10808@gont.com.ar> In-Reply-To: <53036867.10808@gont.com.ar> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/_aTri62WLVSSLCxfDd4mpoWMhOo Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 21:26:49 -0000 Below... On 19/02/2014 03:04, Fernando Gont wrote: > Hi, Brian, > > Thanks so much for your feedback! -- Please find my comments in-line... > > On 02/16/2014 11:50 PM, Brian E Carpenter wrote: >> Hi, >> >> I think this is the right way to close off the EUI-64 debate. >> Just a couple of small comments: >> >>> NOTE: [RFC4291] defines the "Modified EUI-64 format" for Interface >>> identifiers. Appendix A of [RFC4291] then describes how to transform >>> an IEEE EUI-64 identifier, or an IEEE 802 48-bit MAC address from >>> which an EUI-64 identifier is derived, into an interface identifier >>> in the Modified EUI-64 format. >> I suggest adding something like >> >> [RFC7136] updates RFC 4291 to remove the requirement to use the >> Modified EUI-64 format. > > Will do (assuming no one opposes). > > >> (see http://tools.ietf.org/html/rfc7136#section-5) >> >>> Nodes SHOULD NOT employ IPv6 address generation schemes that embed >>> the underlying hardware address in the Interface Identifier. Namely, >>> nodes SHOULD NOT generate Interface Identifiers with the schemes >>> specified in [RFC2464], [RFC2467], and [RFC2470]. >> Is that list complete? In draft-carpenter-6man-why64 we have >> quite a list of IPv6-over-foo documents. It would perhaps be >> better to s/Namely/In particular/. > > The list might not be complete, since (so far) we haven't done an > exhaustive list of "IPv6 over foo" documents. That said, I think that > all such RFCs should be explicitly identified/listed, since they should > also be included in the "Updates: .." tag/metadata. > > Thoughts? Sure, if you guarantee to find all of them. However, changing the text to "In particular" allows for the case that you miss one or two. Brian From nobody Tue Feb 18 13:38:21 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107DB1A0231 for ; Tue, 18 Feb 2014 12:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZcWd_DWhmqp for ; Tue, 18 Feb 2014 12:05:41 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2361A0221 for ; Tue, 18 Feb 2014 12:05:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=830; q=dns/txt; s=iport; t=1392753938; x=1393963538; h=date:from:to:cc:subject:message-id:mime-version; bh=yxMNpudYnx6tFjjIuRflqbg/OttVKPM/3eavcdJqauQ=; b=MDwyIjrRhMsPuEb5IhrEwUOw3llKjySDCL8FNfM8NH7J+Wzgl9Vak7KF agQ6RHwwXIW15t0M4cVcIKLjs1qiK0g6qHjyOqpGa2Jb3XhhEr2s24iT1 KOKB94DlU2+oI9wXe5F/35dXzDNXN4j5ecyXWB2drLv8dJe1muphhXGh+ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoANAAm8A1OtJV2Z/2dsb2JhbABZgwY4V6gsAwWYAoEfFnSCZAIuES6BEA6ICg3MNheOZB2EIgSZYoUVi12DLoIp X-IronPort-AV: E=Sophos;i="4.97,503,1389744000"; d="scan'208";a="21378989" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP; 18 Feb 2014 20:05:38 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1IK5cX3002795 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Feb 2014 20:05:38 GMT Received: from [10.61.162.197] (10.61.162.197) by xhc-rcd-x02.cisco.com (173.37.183.76) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 18 Feb 2014 14:05:32 -0600 Date: Tue, 18 Feb 2014 21:05:12 +0100 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Subject: draft-yourtchenko-colitti-nd-reduce-multicast-00 Message-ID: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" X-Originating-IP: [10.61.162.197] Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/gtJJWwzYdzDGr9tfzdff4nZXjPY X-Mailman-Approved-At: Tue, 18 Feb 2014 13:38:05 -0800 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 20:05:43 -0000 Hi all, in preparation for the discussion on the matter of the ND chattiness, we wrote a draft summarizing the practical steps taken in practical networks to make IPv6 and WiFi work better together; as well as to think of what incremental and immediately impactful changes may be done. http://tools.ietf.org/html/draft-yourtchenko-colitti-nd-reduce-multicast-00 (I noticed that I missed to delete a small xml2rfc blob from the text, but alas, it was after the deadline, sorry for this). Most of the steps in section 4 were in place for a couple of mid-size events: my employer's conference CiscoLive 2014 (stats at http://2014.ciscolive-ipv6.com/munin/ipv6noc/ipv6noc/index.html), and an open-source conference in Brussels called FOSDEM (similar quantities of the devices within a single /64). --a From florent.fourcot@enst-bretagne.fr Sun Feb 16 12:33:27 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6F71A0068 for ; Sun, 16 Feb 2014 12:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRuhdrY5qmd7 for ; Sun, 16 Feb 2014 12:33:25 -0800 (PST) Received: from olfflo.fourcot.fr (fourcot.fr [IPv6:2001:4b98:dc0:41:216:3eff:fe52:be3b]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9BE1A029B for <6man@ietf.org>; Sun, 16 Feb 2014 12:33:25 -0800 (PST) Received: from reglisse.fourcot.fr (unknown [IPv6:2001:470:6d:5e8:227:10ff:feef:b458]) (Authenticated sender: reglisse) by olfflo.fourcot.fr (Postfix) with ESMTPSA id 9E6062DF38 for <6man@ietf.org>; Sun, 16 Feb 2014 21:33:21 +0100 (CET) Received: from [IPv6:::1] (localhost [IPv6:::1]) by reglisse.fourcot.fr (Postfix) with ESMTPS id E6229805569 for <6man@ietf.org>; Sun, 16 Feb 2014 21:33:20 +0100 (CET) Message-ID: <53012090.3080602@enst-bretagne.fr> Date: Sun, 16 Feb 2014 21:33:20 +0100 From: Florent Fourcot User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: 6man@ietf.org Subject: Status of the "u" bit for privacy extensions Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/-RoZND_1wmzgLCOaWbkMsIll9Y8 X-Mailman-Approved-At: Tue, 18 Feb 2014 13:38:10 -0800 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 21:02:44 -0000 Hello, the RFC 7136 has removed/clarify the significance of bits in interface identifier for future iids generation, but it does not include any reference to some current iids generation. For example, the RFC 4941 asks to set the bit 6 to zero: http://tools.ietf.org/search/rfc4941#section-3.2.1 Should current implementations following this rule be updated? What is the current rule for this? Regards, -- Florent. From nobody Tue Feb 18 13:50:00 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7F11A03FD for ; Tue, 18 Feb 2014 13:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1Qc_8lyDT-V for ; Tue, 18 Feb 2014 13:49:53 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id A8AC11A0405 for ; Tue, 18 Feb 2014 13:49:53 -0800 (PST) Received: from dhcp-10-61-101-237.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 87E7C606A; Tue, 18 Feb 2014 13:49:49 -0800 (PST) From: Ole Troan Content-Type: multipart/signed; boundary="Apple-Mail=_87BDD9F6-52EF-4E55-A265-7D8EE3D07F8A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: Draft 6man agenda out Date: Tue, 18 Feb 2014 22:49:48 +0100 Message-Id: <4293CC2D-4142-4850-973A-8B1E8B7E7EEA@employees.org> To: 6man WG Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Rp9kmJtegrRLw9n54FMHph9guCI Cc: 6man Chairs <6man-chairs@tools.ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 21:49:58 -0000 --Apple-Mail=_87BDD9F6-52EF-4E55-A265-7D8EE3D07F8A Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii The preliminary agenda of the 6man working group session for London is out: https://datatracker.ietf.org/meeting/89/agenda/6man/ Best regards, Bob & Ole --Apple-Mail=_87BDD9F6-52EF-4E55-A265-7D8EE3D07F8A 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 iQEcBAEBCgAGBQJTA9V8AAoJEFuJXizso86gidIH/3Uflc53b1Lix15GZFRFc/ga sQ+5+vSpl+jgpLrpe/GETKKGuRpArm2HihukfLl2p4f6gN6mqphIOF4mDjKD4BdF HKuc5LnmnOyl9DqyLyQBwKcytIT5QorSbVh5y6ZceNFnSGMlsH1a1hSndlIpjO7a dtIN9qJwqhv3dxEgmCgZEr/sMk6W4EO6Wxq27ZcaKDiVEaeSIg7qi9wnTW2gZbh2 9YuUbJOM/aCcjv6fi8PahRgwcf+zASljI6cXV5UgnjRk68rzxbjDUT1ACdOWrF8q eUHDbQ27NuRHhbleRkKb7QREbrY5g5fqQktVnn+NZDr21CTQ7h8bEMzeO5bccOs= =1TcI -----END PGP SIGNATURE----- --Apple-Mail=_87BDD9F6-52EF-4E55-A265-7D8EE3D07F8A-- From nobody Tue Feb 18 17:11:51 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B961A00F5 for ; Tue, 18 Feb 2014 17:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_MXp3ihZhli for ; Tue, 18 Feb 2014 17:11:47 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9629A1A0168 for ; Tue, 18 Feb 2014 17:11:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5556; q=dns/txt; s=iport; t=1392772305; x=1393981905; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=SxdUq6rq16beVgfLTjA70bqekBVYivdvcCH8NnG3G1c=; b=Fhxoj7/etJ47yu2oKxnNUauWRt2J9cK9+9pgiiIS14Fpla0o1s/5J64S WKidGLcJ7drxikabphCOUuhwCHjCCgLdYkSm5+3qxKjBqN5hIuqjZwLme OYQYHE1K0Z8n/fNszuaMpJE+65DaFG3CToTjURFeLOZsKdi+e2pgIsnfH c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFACUEBFOtJXG//2dsb2JhbABZgwaBD8BBgSIWdIIlAQEBBCcTSwQCAQgRBAEBCxQJBzIUCQgCBAESCBOGAoFozFYXjgIRAR84BoMegRQEqlSDLYFoBwIXIg X-IronPort-AV: E=Sophos;i="4.97,503,1389744000"; d="scan'208";a="304965989" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 19 Feb 2014 01:11:44 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1J1Bi8u018748 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Feb 2014 01:11:44 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 19:11:44 -0600 From: "Hemant Singh (shemant)" To: Jouni Korhonen , "draft-ietf-6man-enhanced-dad@tools.ietf.org" , IPv6 IPv6 List Subject: RE: comments on draft-ietf-6man-enhanced-dad-04 Thread-Topic: comments on draft-ietf-6man-enhanced-dad-04 Thread-Index: AQHPJnnvIN69lWyYR0GTaz9EzyMcQ5q7yQGA Date: Wed, 19 Feb 2014 01:11:43 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89115F5DD1@xmb-rcd-x06.cisco.com> References: <78AE6729-1A26-48EA-BD31-FBBDE85C829E@gmail.com> In-Reply-To: <78AE6729-1A26-48EA-BD31-FBBDE85C829E@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.246.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Q4zduJwdhqukJc_xOXZHp5Lhi5w X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 01:11:50 -0000 Jouni, Good to hear from you - thanks much for the review. Humble apologies for t= he delay - both WesB and I were busy. We discussed your comments. Pleas= e see in line below between and . -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Monday, February 10, 2014 11:05 AM To: draft-ietf-6man-enhanced-dad@tools.ietf.org; IPv6 IPv6 List Subject: comments on draft-ietf-6man-enhanced-dad-04 Authors, I have a read on this document. I find it good and informative. Few comment= s and questions inline. ** Abstract o There is no mention that this document updates RFC4861 and RFC4862. The reason is because the top-left of the document says "Update: 4862,= 4861". Would you like the Abstract to also mention the same fact? WE wi= ll also add that this document also updates the SEND RFC. ** Section 1 specified in [RFC4862]. Failure also includes if the Target Address is optimistic. Optimistic DAD is specified in [RFC4429]. o I do not understand the sentence "Failure also includes if the Target Address is optimistic." Some word missing there? I meant to say, the failure covers both a tentative and an optimistic = address where the tentative address is defined in RFC 4862 and the optimist= ic address is defined in RFC 4429. Either address type can be the TargetA= ddress of the DAD probe . Either address type can also fail DAD due to a l= ooped back DAD and both protocols use the same failure mechanism defined in= RFC 4861.=20 New text: [Duplication Address Detection failure as specified in [RFC4862]. Note e= ven Optimistic DAD as specified in [RFC4429] can fail due to a looped back= DAD probe. This document covers looped back detection for Optimistic DAD= as well. ] =20 ** Section 3.2 This solution requires no protocol changes. This solution SHOULD be enabled by default, and MUST be a configurable option. o I would clarify here, just to be clear on the context, that the above MUST applies only if the layer 2 has an ability to detect looped back messages. Proposed text: This solution requires no protocol changes. This solution SHOULD be enabled by default, and MUST be a configurable option if the layer 2 technology provides means for detecting loopback messages on an interface circuit. Perfect suggestion and thanks for the text. We will take the text. <= /hs> ** Section 4 SEND. See more details in the Impact on SEND section. Since a nonce ^^^^^^^^^^^^^^^^^^^^^^^ o I would point explicitly to the section number as well. ok. o The algorithm description in the second paragraph is somewhat hard to follow. I had to read it quite many times.. On the other hand, the algorithm description in Section 4.2 is far more readable. Consider having the algorithm description only in one place. Agreed. Most of the second paragraph will be deleted and we will refe= rence section 4.2 in the second paragraph. ** Section 4.2 The MAX_MULTICAST_SOLICIT number of NS(DAD) messages sequence continues until the stop condition is reached. o Or manual administrative actions are taken, right? Yes. New text below: The MAX_MULTICAST_SOLICIT number of NS(DAD) messages sequence continues = until the stop condition is Reached or manual intervention is undertaken. o The stop condition and ending the probing means the interface moves the Target Address to assigned state, right? I would say that explicitly. OK - will do. Note one reviewer (in private email) wanted the address= to move to assigned state whether a looped back DAD was received within th= e RetransTimer milliseconds interval or not. But I replied, what good is a= n assigned address until I the interface detects the loopback has stopped b= ecause unless the loopback stops, the assigned address can be used to only = to send traffic that is looped right back. =20 ** Section 4.4 detecting looped back ND messages. If this document updates [RFC4862], SEND should be updated to integrate with the Enhanced DAD algorithm. A minor update to SEND would be to explicitly mention o "If this document updates.." well it does. Propose changing the text to something like "Since this document.." o Why there is no proposal for those "minor" SEND updates? Will take your suggestion and propose text in our next revision. ** Section 4.5 The following text is added to [RFC4862]. o Added where in RFC4862? Propose an explicit place. o The added text should probably have a reference to this document. Ok, will do. ** Section 4.6 o Changes where exactly in RFC4861? Propose an explicit place. o The added text should probably have a reference to this document. Ok, will do. ** Section 6 algorithm. SEND is recommended for this exploit. For any mitigation o I would say SEND is not recommend for this exploit rather SEND is recomme= nded to circumvent this exploit. Agreed. Will take your suggestion. ** Section 9 o Obsolete normative reference to RFC1247 (obsoleted by RFC1583) o No refer= ence to RFC2119 (also there is no typical RFC2119 boilerplate text) o draft= -ietf-6man-impatient-nud -> RFC7048 will do Thanks much, Hemant From nobody Tue Feb 18 20:18:44 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160F31A0129 for ; Tue, 18 Feb 2014 20:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEv9DLpLJfTL for ; Tue, 18 Feb 2014 20:18:38 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABE21A02FD for ; Tue, 18 Feb 2014 20:18:37 -0800 (PST) Received: from [2001:5c0:1400:a::12e3] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WFycD-00043I-1o; Wed, 19 Feb 2014 05:18:33 +0100 Message-ID: <53042ACA.1070103@gont.com.ar> Date: Wed, 19 Feb 2014 00:53:46 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: I-D Action: draft-ietf-6man-default-iids-00.txt References: <20140124142141.1829.4747.idtracker@ietfa.amsl.com> <530178E1.6010206@gmail.com> <53036867.10808@gont.com.ar> <5303D017.4070304@gmail.com> In-Reply-To: <5303D017.4070304@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/UNbwHZTAv79ewXdeJVvrpQ22ezs Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 04:18:42 -0000 On 02/18/2014 06:26 PM, Brian E Carpenter wrote: >>> >>>> Nodes SHOULD NOT employ IPv6 address generation schemes that embed >>>> the underlying hardware address in the Interface Identifier. Namely, >>>> nodes SHOULD NOT generate Interface Identifiers with the schemes >>>> specified in [RFC2464], [RFC2467], and [RFC2470]. >>> Is that list complete? In draft-carpenter-6man-why64 we have >>> quite a list of IPv6-over-foo documents. It would perhaps be >>> better to s/Namely/In particular/. >> >> The list might not be complete, since (so far) we haven't done an >> exhaustive list of "IPv6 over foo" documents. That said, I think that >> all such RFCs should be explicitly identified/listed, since they should >> also be included in the "Updates: .." tag/metadata. >> >> Thoughts? > > Sure, if you guarantee to find all of them. However, changing the > text to "In particular" allows for the case that you miss one or two. Makes sense. Will do. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Tue Feb 18 21:06:30 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FEF1A04D3 for ; Tue, 18 Feb 2014 21:06:28 -0800 (PST) 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=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yR9U6iLnboBP for ; Tue, 18 Feb 2014 21:06:25 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2CF1A04B7 for ; Tue, 18 Feb 2014 21:06:25 -0800 (PST) Received: from [2001:5c0:1400:a::12e3] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WFzMK-0005Gt-BE; Wed, 19 Feb 2014 06:06:12 +0100 Message-ID: <530432FF.8080704@si6networks.com> Date: Wed, 19 Feb 2014 01:28:47 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: ek , "Hemant Singh (shemant)" Subject: Re: Reducing the battery impact of ND References: <52D96663.6060005@sonic.net> <52DA0ABA.8030903@acm.org> <52E03BB4.8040309@acm.org> <52E0423A.5070906@acm.org> <01DC3532-C73A-4644-A323-04BE6231AADA@employees.org> <52E9EF2D.9050402@acm.org> <2CFF305E-DE44-4D57-82D3-241196D94610@employees.org> <52ECA6EE.1080201@acm.org> <75B6FA9F576969419E42BECB86CB1B89115D182D@xmb-rcd-x06.cisco.com> <1315813580.259590.1392631505190.JavaMail.sas1@[172.29.252.247]> In-Reply-To: <1315813580.259590.1392631505190.JavaMail.sas1@[172.29.252.247]> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/O7j7uCbxejDi2QR2K8wk9Yjbe8s Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Andrew Yourtchenko , 6man WG , Erik Nordmark X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 05:06:28 -0000 On 02/17/2014 07:05 AM, ek wrote: > > If the community is interested in supporting a new ethertype for IPv6 ND, please let me know. I would expedite an I-D from Cisco who has IPR related to the new ethertype. See > > > > http://www.google.com/patents/US8102854 > > I haven't read this, but, IMHO, the potential existence of IPR about using a new ethertype for NUD messages is a wonderful reason to *never ever* do this. Can *that* have an IPR??? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Feb 18 21:19:18 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E11D1A0422 for ; Tue, 18 Feb 2014 21:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntd43AJ5maEB for ; Tue, 18 Feb 2014 21:19:16 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id DCEB81A03E6 for <6man@ietf.org>; Tue, 18 Feb 2014 21:19:15 -0800 (PST) Received: from [2001:5c0:1400:a::12e3] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WFzYr-0005Ws-IE; Wed, 19 Feb 2014 06:19:09 +0100 Message-ID: <53043E50.2010604@gont.com.ar> Date: Wed, 19 Feb 2014 02:17:04 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Florent Fourcot , Fernando Gont Subject: Re: Status of the "u" bit for privacy extensions References: <53032F9D.50203@flo.fourcot.fr> <53035F12.6090208@si6networks.com> <5303AF2E.3090701@flo.fourcot.fr> In-Reply-To: <5303AF2E.3090701@flo.fourcot.fr> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/-0j-EyutoH-l_cI-1N5UXPBALEc Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 05:19:17 -0000 Florent, On 02/18/2014 04:06 PM, Florent Fourcot wrote: > >> That said, in the light of RFC7136, it would probably make sense to use >> the semantics in RFC7136. > > Thanks Fernando. I'm afraid, it will probably not enough convincing for > Linux kernel developers to change the current behaviour. They need not. If they implement RFC4941, that's what they should be complying with. RFC7136 *has not* updated RFC4941 in this respect. When we did draft-ietf-6man-stable-privacy-addresses (currently in the RFC Editor queue), we took the advice from RFC7136 and thus treat all 64 bits of the IID as an opaque value. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Wed Feb 19 23:30:41 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD0C1A0422 for ; Wed, 19 Feb 2014 23:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsIrEWhvdVY4 for ; Wed, 19 Feb 2014 23:30:37 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2737A1A037D for ; Wed, 19 Feb 2014 23:30:37 -0800 (PST) Received: from [10.0.1.44] (184-23-158-127.dsl.dynamic.sonic.net [184.23.158.127]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s1K7URjO031580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Feb 2014 23:30:28 -0800 Message-ID: <5305AF13.5060201@acm.org> Date: Wed, 19 Feb 2014 23:30:27 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: IETF IPv6 , Lorenzo Colitti , "Andrew Yourtchenko (ayourtch)" Subject: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;comR3gCa4xG1i6b+H0/FGg== M;KDa73gCa4xG1i6b+H0/FGg== Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/I_nDHIDL_d__mKyg2xCNQsGV2wM X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 07:30:39 -0000 Thanks for putting this draft together. Some questions and comments below. In section 3 you have: * One solicited RA per host joining the network (if solicited RAs are sent using multicast) That isn't entirely true. Because of the rate limiting of multicast RAs if a lot of hosts join at the same time, then there will be less. In section 4.2 we can suggest an implementation that does unicast: If we believe that the flash crowd case is still important (when we wrote ND the concern was around a building power failure and recovery - today it might be a stadium setting), then one could implement a mix as follows: - When RS received start timer. - If N additional RSs arrives before timer fires, then multicast one RA. Otherwise when timer fires unicast RAs to the received RSs. For N=1 this is trivial. In section 4.3 there are two suggestions: MLD snooping and L2 unicast or L3 multicast packets. I think there are some operational concerns around MLD snooping - I hope others can fill in some information in that space since I don't know the issues. (Editorially it would be clearer if those two are separate sub-sections.) The multicast-over-unicast refers to SAVI as a way to collect the state, but it doesn't specify where you see that state used. Presumably for DAD (and NS in general unless you also do section 4.7)? But SAVI doesn't claim to have all addresses since it is concerned with conflicts. Thus a host can exist and be silent - but DAD would still expect to reach it. Or a host could have moved to a different port and SAVI having stale state - yet DAD should work. My point is that the details of how the state is 1) maintained and 2) used to forward packets are key to analyzing how the neighbor discovery functionality and robustness would be affected by this idea. I section 4.4 the document refers to proxy but without specifying which of the different proxy approaches you have in mind. There is the proxy ND RFC, and there is the DAD proxy internet-draft in 6man. Are you referring to one of those, or some slightly different form of proxy? (For example, ND proxy would respond with the LLA of the router/AP, but that might result in host movement looking like a duplicate address - again depends on the details.) I don't have any issue with removing the somewhat arbitrary 9000 second max AdvDefaultLifetime in section 5.1. However, the tradeoff for what default lifetime to use in section 4.5 needs to take into account one additional factor. The default lifetime serves to garbage collect entries from the default router list should a router silently disappear. Thus for links that do not have a fixed (set of) link-local address(es) for the router(s), having a high default lifetime means that after a failure the hosts would have one entry in the default router list which us unreachable - until that high lifetime expires. I don't know if there has been a study on the performance impact of that would have on the hosts e.g., how often they would re-probe the default router. Section 4.6 has the same concern. But 4.5 and 4.6 makes lots of sense e.g., in a VRRP deployment where the link-local address of the virtual default router would always be the same. Ditto for networks with a single point of failure single router at a fixed address (e.g., if the router is always at fe80::1 or some other fixed address.) Thus I think we should recommend 4.5 and 4.6 that within that applicability. Added benefit is that the routers control it, hence the operator of the network can set the values higher for VRRP or single router cases. Section 4.7 talks about limiting the table space on the hosts. But clearing the on-link bit in the advertised prefixes also has the benefit of removing any multicast NS sent from hosts for non-link-local destinations. And per RFC 4861 the table will be filled in by the router sending redirects. Thus the router can be used to control which addresses get in the tables on the hosts by choose whether and when to send the redirects (redirects with target==destination). In think it would be good to separate out the second half of section 4.7 (blocking link-locals) into a separate section, since it is quite different than clearing the on-link bit. That idea has significant implications since it changes the IP subnet model (RFC 4903 talks about this.) I not saying that we shouldn't consider this, but I do think it would fall in a very different category than the other ideas in this draft. Might even be best to have a separate draft on this radical idea so it can be explored fully. 4.8 seems to conflate the address assignment with DAD. Just because we might want to centralize the DAD checks doesn't imply that we want to remove the ability for the host to pick its own privacy enhanced interface-IDs to form its addresses. From a deployment perspective DHCPv6 is available for address assignment, but don't think we want to require that for WiFi or other links which have packet loss. (Packet loss occurs on wired networks as well, but the drop distribution is different - might happen during spanning tree reconvergence etc.) Note that DHCPv6 (RFC 3315) has a SHOULD for doing DAD on the addresses received from the DHCP server - needed since the server could be confused. In don't understand 4.9. Should I read it as a host shutting things down if it goes to sleep even for a short time, and then waking up and multicasting a few RSs to get RAs, then multicasting a DAD probe for each assigned IPv6 address? If all the hosts did that then I think there would be more multicasts. Note that even if the host doesn't revert to multicasting RSs, it still needs to be concerned about a duplicate address having arrived on the link while it was asleep (and not responding to any DAD probes.) The suggestion in section 5.2 is needs a lot more work. I tried to work out some of these issues in section 8.9 in draft-chakrabarti-nordmark-6man-efficient-nd-05. But even if we figure out how to do that without causing lots of unneeded RS load on the routers, in the case of your draft wouldn't the router(s) still need to multicast RAs at the same frequency? The router(s) have no way to know whether all the hosts on the link initiate RS to refresh RA information. Regards, Erik From nobody Thu Feb 20 07:03:33 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DB71A01BE for ; Thu, 20 Feb 2014 07:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZivLzBRgyD82 for ; Thu, 20 Feb 2014 07:03:28 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 60D2E1A0183 for ; Thu, 20 Feb 2014 07:03:28 -0800 (PST) Received: from dhcp-10-61-103-42.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 38591670A; Thu, 20 Feb 2014 06:43:18 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_F702BDC9-3511-45AC-AB81-1AA73E3A6906"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast From: Ole Troan In-Reply-To: <5305AF13.5060201@acm.org> Date: Thu, 20 Feb 2014 15:43:15 +0100 Message-Id: <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org> References: <5305AF13.5060201@acm.org> To: Erik Nordmark X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/n2Lifj_JLP-NBLcMpyLC2PKBABU Cc: Andrew Yourtchenko , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 15:03:30 -0000 --Apple-Mail=_F702BDC9-3511-45AC-AB81-1AA73E3A6906 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > 4.8 seems to conflate the address assignment with DAD. Just because we = might want to centralize the DAD checks doesn't imply that we want to = remove the ability for the host to pick its own privacy enhanced = interface-IDs to form its addresses. > =46rom a deployment perspective DHCPv6 is available for address = assignment, but don't think we want to require that for WiFi or other = links which have packet loss. (Packet loss occurs on wired networks as = well, but the drop distribution is different - might happen during = spanning tree reconvergence etc.) > Note that DHCPv6 (RFC 3315) has a SHOULD for doing DAD on the = addresses received from the DHCP server - needed since the server could = be confused. I'd like to explore the difference between DHCP address assignment and = ND address registration a little more. the state that is required in the network for "efficient ND", why cannot = that be created and maintained by DHCP? there are multiple ways of dealing with DAD in this scenario, including = solutions that don't require host changes. DHCP also supports temporary addresses btw. cheers, Ole --Apple-Mail=_F702BDC9-3511-45AC-AB81-1AA73E3A6906 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 iQEcBAEBCgAGBQJTBhSEAAoJEFuJXizso86gRfQIAJT1r+MqDB+MXxqpVnh2k3Uo In2eG48ro8SyzKg+KD7hDDFj/+ha+MeGnWklwVqQNvbsZpTBzNOMyNJBrk5oWcYw NvdtQWeX1wfHW638Wezm/Q/qFJ62m04LtG5X1HkikxbSO8JUfKa3k+pc9w2AfrVC xxkhrJXf2jqxJTup4HwNdv0pC2fkKS/Ve3vA0lgUQSvq6a0n8IC+sAifaumZHuAL CuzIVg2T/4KRXOMNk+Ufx8zmF1DA+XJmvwm2O7agbmMafk9+PXv9qbJsm9HibehT xeetfGfo7cosM1mzhmuY0bincn3bOuY4nLLfBpq51jYN49nG3+aFQ72PWVGUlo4= =LHZ8 -----END PGP SIGNATURE----- --Apple-Mail=_F702BDC9-3511-45AC-AB81-1AA73E3A6906-- From nobody Thu Feb 20 23:00:16 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F64B1A0217 for ; Thu, 20 Feb 2014 08:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.15 X-Spam-Level: X-Spam-Status: No, score=-10.15 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUZEAvgofYBU for ; Thu, 20 Feb 2014 08:56:29 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id CDA651A0212 for ; Thu, 20 Feb 2014 08:56:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19264; q=dns/txt; s=iport; t=1392915385; x=1394124985; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=9/pWU1KtZQwe9ENg4TGmrnKVZM3XEjlRXthsAGJiZP4=; b=QcbnvFGZVbGLGHyutgJ3yVEnqn6vzoMBTKQJUCcmgCJVgFr/MvmVEvDR XNyRZkf6yTkY8kpTJgawtjVNhQGMKtzQGzA+ANPZvitZg61gRWEjUuCQo DXi6sFW2wliaVHaDgzVpwwdbE7AM4iCHqJTr6FQwC1dXH/4N/gjb7gCn0 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYJAGMzBlOtJV2a/2dsb2JhbABZgwY4V6gEA5gHgRAWdIIlAQEBAgEBJxECKw0HBQsLLRlXBg4eAgOHXwgNzkEXjXwRAwZJBQcKhC4ElEeWDYMugWcBBhkEHg X-IronPort-AV: E=Sophos;i="4.97,513,1389744000"; d="scan'208";a="21924125" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP; 20 Feb 2014 16:56:21 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1KGuLHx032188 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Feb 2014 16:56:21 GMT Received: from ams3-vpn-dhcp3495.cisco.com (10.61.77.167) by xhc-rcd-x15.cisco.com (173.37.183.89) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 20 Feb 2014 10:56:20 -0600 Date: Thu, 20 Feb 2014 17:56:02 +0100 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Erik Nordmark Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast In-Reply-To: <5305AF13.5060201@acm.org> Message-ID: References: <5305AF13.5060201@acm.org> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" X-Originating-IP: [10.61.77.167] Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/80KaSmyL7kMQ3zUlYs57ufgAy8o X-Mailman-Approved-At: Thu, 20 Feb 2014 23:00:15 -0800 Cc: IETF IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 16:56:33 -0000 On Wed, 19 Feb 2014, Erik Nordmark wrote: > > Thanks for putting this draft together. Some questions and comments below. > > In section 3 you have: > * One solicited RA per host joining the network (if solicited RAs are sent > using multicast) > That isn't entirely true. Because of the rate limiting of multicast RAs if a > lot of hosts join at the same time, then there will be less. agreed. If more than one host joins within ~ 3 seconds interval, only one multicast RA will be sent. I'll update the next rev with this clarification. > > In section 4.2 we can suggest an implementation that does unicast: > If we believe that the flash crowd case is still important (when we wrote ND > the concern was around a building power failure and recovery - today it might > be a stadium setting), then one could implement a mix as follows: > - When RS received start timer. > - If N additional RSs arrives before timer fires, then multicast one RA. > Otherwise when timer fires unicast RAs to the received RSs. > For N=1 this is trivial. Yeah, it's a very useful optimization to consider, we discussed it I think alread. The reason I did not include it yet, was to go over the tradeoffs without the pressure of the submission deadline being a few hours away :) 1) from the efficiency standpoint this approach is fantastic for the wired and for the wireless (the implementations that do the mcast->ucast conversion over the air the win is a bit less, but nonetheless there is a win since we send only one packet on the wired side instead of many and save the CPU on the gateway). 2) This adds an instantaneous behavior change into the network at the peak load conditions - so if that code path has a problem, this creates hard-to-debug situation. 3) There are a few trickier scenarios with L3 roaming (hosts arriving from other subnets onto the same AP) and that AP having a single 802.11 group encryption key, which this behavior might make easier to accidentally have broken. But, all in all it can be very useful to have a knob to allow to send a multicast RA at the time when the gateway can't handle the flood of incoming RS anyway and has to drop them. > > In section 4.3 there are two suggestions: MLD snooping and L2 unicast or L3 > multicast packets. I think there are some operational concerns around MLD > snooping - I hope others can fill in some information in that space since I > don't know the issues. > (Editorially it would be clearer if those two are separate sub-sections.) > > The multicast-over-unicast refers to SAVI as a way to collect the state, but > it doesn't specify where you see that state used. Presumably for DAD (and NS > in general unless you also do section 4.7)? But SAVI doesn't claim to have > all addresses since it is concerned with conflicts. Thus a host can exist and > be silent - but DAD would still expect to reach it. Or a host could have > moved to a different port and SAVI having stale state - yet DAD should work. > My point is that the details of how the state is 1) maintained and 2) used to > forward packets are key to analyzing how the neighbor discovery functionality > and robustness would be affected by this idea. The hosts that are "quiet" are indeed a problem. However, I think it might be very OS-specific - the today's smartphones are anything but quiet :-) So I think this will be much more of an issue for some special-purpose devices, which are also predominantly servers. I think the smart-meter type of device would be in this category. But to access those, the remote party will need to know their address... so, if a device does some sort of service registration upon boot-up, then it will not be a quiet device anymore. I haven't seen this failure in the "consumer portable devices" networks that I ran - so this is purely a mental construct. I do agree that there are limitations - but I think it is very important to collect the data about the scope of these limitations, to keep a balanced approach. The data I have as of today based on 5-6 networks with 10-20K hosts says it is quite minimal. But I reserve the right to be wrong and thus would be very interested to hear about other live networks where it is different. (side note: if these sleepy hosts are quiet and are concerned that their address be known, they might consider to use DHCPv6 as well). > > I section 4.4 the document refers to proxy but without specifying which of > the different proxy approaches you have in mind. > There is the proxy ND RFC, and there is the DAD proxy internet-draft in 6man. > Are you referring to one of those, or some slightly different form of proxy? > (For example, ND proxy would respond with the LLA of the router/AP, but that > might result in host movement looking like a duplicate address - again > depends on the details.) I don't know the spec. I saw it implemented in a product, where two attached clients A and B during the ND saw the packet sequences that were close enough to the ND spec to achieve identical practical result and be compliant to the letter of it, yet allowed to perform the process more optimally from the broader perspective. Arguably this kind of behavior would not require its own spec ? > > I don't have any issue with removing the somewhat arbitrary 9000 second max > AdvDefaultLifetime in section 5.1. However, the tradeoff for what default > lifetime to use in section 4.5 needs to take into account one additional > factor. > The default lifetime serves to garbage collect entries from the default > router list should a router silently disappear. Thus for links that do not > have a fixed (set of) link-local address(es) for the router(s), having a high > default lifetime means that after a failure the hosts would have one entry in > the default router list which us unreachable - until that high lifetime > expires. I don't know if there has been a study on the performance impact of > that would have on the hosts e.g., how often they would re-probe the default > router. This is indeed a useful consideration that is worth noting in a doc that would be removing the 9000 seconds max limit. Mind if sketch a -00 on this matter and send you the possible text ? > > Section 4.6 has the same concern. But 4.5 and 4.6 makes lots of sense e.g., > in a VRRP deployment where the link-local address of the virtual default > router would always be the same. Ditto for networks with a single point of > failure single router at a fixed address (e.g., if the router is always at > fe80::1 or some other fixed address.) Thus I think we should recommend 4.5 > and 4.6 that within that applicability. Added benefit is that the routers > control it, hence the operator of the network can set the values higher for > VRRP or single router cases. I totally agree! We probably might have a series of documents for different types of use cases - this could be very helpful for the folks deploying them. We could turn this doc into a "large-scale high-density WiFi (stadiums, exhibitions, campuses, etc.)" and then have couple of others describing other types of deployments. Let's discuss this in London ? > > Section 4.7 talks about limiting the table space on the hosts. But clearing > the on-link bit in the advertised prefixes also has the benefit of removing > any multicast NS sent from hosts for non-link-local destinations. And per RFC Yes, it's an omission by implication. Very good thing to note though, will fix, thanks! > 4861 the table will be filled in by the router sending redirects. Thus the > router can be used to control which addresses get in the tables on the hosts > by choose whether and when to send the redirects (redirects with > target==destination). Absolutely, thanks for this mention, I forgot to write this. Yes, this section is incomplete without mentioning that the routers have to have the redirects off, indeed. > > In think it would be good to separate out the second half of section 4.7 > (blocking link-locals) into a separate section, since it is quite different > than clearing the on-link bit. That idea has significant implications since > it changes the IP subnet model (RFC 4903 talks about this.) I not saying that > we shouldn't consider this, but I do think it would fall in a very different > category than the other ideas in this draft. Might even be best to have a > separate draft on this radical idea so it can be explored fully. I thought RFC5942 was clarifying this (by the way I need to reference it). My thought process was as follows: suppose we have 9000 people, each with a smartphone, wandering inside a large building or on campus. We want to limit the broadcast domains. So we will split these 9000 hosts into 256 subnets, each with 35-36 hosts. Those are small enough to be close to what is a typical "small network" so everything will be fine, and the protocols which do use link-local addresses will actually be able to function. Good ? Seems so, but, there are problems with this approach: 1) "Lobby ambassador" problem: everyone arrives through the same entrance, and turns on their portable device there. Therefore, the assignment of a host to the subnet must happen there, not based on physical location, but on some loadbalancing algorithm. I have 256 subnets, so e.g. for predictability we can use a first byte of a hash of the host's mac address. 2) I need to span those 256 vlans across the entire venue, and ensure I place each of the hosts into the correct VLAN on each AP. A typical network of such a scale will have about 300 APs. I still need to send RAs within each vlan. I need to ensure that the hosts do not receive the "wrong" RAs. (and remember, there is not really a way in a naive 802.11 imlementation to do "selective" multicast). 3) I have people that are able to see each other using multicast advertisements, but what relation do they have to each other ? Equality of the first byte of the hash of their mac address. Not very useful. So I conclude, that while splitting the whole crowd into smaller subnets somewhat takes care of the floods at the expense of additional complexity, the resulting "working" link-local multicast protocols do not really make any sense - because the partition of the network does not have any other logic than pure loadbalancing. So, I decide to explore the dimension of optimizing the multicast-limiting properties, and increase the number of subnets. Extrapolating, we get that having a subnet per host seems to be the most logical approach. (Actually there is even a shipping product that does exactly this - a per-host unicast-only RAs with different /64s). But since I have only one /64, I decide that not-on-link+no-redirect should give me the same functionality within a much smaller address space. So, rather than have a bunch of per-host /64s, with a router forwarding between them, I get a bunch of per-host /128s and get a much more compact solution - because now I need to send only *one* RA per AP, and even if it needs to be a multicast one, it is not a catastrophy. Of course, I need to disclaim: doing this in the home network with one AP and < 100 devices all belonging to a single person is not useful at all. Doing this in a network with 9000 devices belonging to different people is the thing that made the most sense. Now that we've cut off all the services, we need to figure out how to bring them back... And I think the further mental construct here that would be useful is to consider this as a giant homenet with a lot of guests. Thus, I think from the services discovery standpoint, the products of the DNS-SD workgroup will be very beneficial here. > > 4.8 seems to conflate the address assignment with DAD. Just because we might > want to centralize the DAD checks doesn't imply that we want to remove the > ability for the host to pick its own privacy enhanced interface-IDs to form > its addresses. > From a deployment perspective DHCPv6 is available for address assignment, but > don't think we want to require that for WiFi or other links which have packet > loss. This is more of a fallback scenario for those who want a 100% guarantee of address uniqueness in the network - using the existing mechanism. Also as a trigger for another small discussion: I think it's worth modeling the real-world experience in the networks with varying packet loss to see at which point it stops being usable, and go from there. The classic IETF "Built-in hotel WiFi" topic: is it worth being extra-sure that DAD works in that scenario ? Or is it worth fixing the connectivity by bringing the loss down to acceptable level ? At how many retransmits do we declare a failure ? Could we then explore a similar approach to make the DAD more robust instead - keeping in mind the probability of failure should be quite low ? This will be a good robustness improvement for the hosts that will immediately benefit them. > (Packet loss occurs on wired networks as well, but the drop > distribution is different - might happen during spanning tree reconvergence > etc.) > Note that DHCPv6 (RFC 3315) has a SHOULD for doing DAD on the addresses > received from the DHCP server - needed since the server could be confused. > yeah. > In don't understand 4.9. Should I read it as a host shutting things down if > it goes to sleep even for a short time, and then waking up and multicasting a depends on the definition of "short". Some hosts nap during the 100ms interval between the 802.11 beacons. Obviously would not work here. Maybe not do it within 5 seconds of turning the screen off. But I certainly know my gadgets stop being reachable if I do not touch them for a day" > few RSs to get RAs, then multicasting a DAD probe for each assigned IPv6 > address? If all the hosts did that then I think there would be more > multicasts. > Note that even if the host doesn't revert to multicasting RSs, it still needs > to be concerned about a duplicate address having arrived on the link while it > was asleep (and not responding to any DAD probes.) > > The suggestion in section 5.2 is needs a lot more work. I tried to work out > some of these issues in section 8.9 in > draft-chakrabarti-nordmark-6man-efficient-nd-05. > But even if we figure out how to do that without causing lots of unneeded RS > load on the routers, in the case of your draft wouldn't the router(s) still > need to multicast RAs at the same frequency? The router(s) have no way to > know whether all the hosts on the link initiate RS to refresh RA information. Sure it needs more whiteboarding. But if we assume one MAC address = one stack (this is a fair assumption I think?), it should be possible, here is a raw idea: By the destination of the RS being unicast, the router knows the host is "resolicit-capable". The source address contains the MAC address, so it is sufficient information to create a neighbor entry with a flag "resolicit-capable" in it. Subsequent neighbor entries with the same MAC address will inherit the "resolicit-capable" in it. (Data structure detour: don't have to index by MAC address to do this. Take two counting bloom filters "legacy hosts' MAC addresses" and "resolicit-capable hosts' MAC addresses". In case of a false positive match, prefer the membership in the "legacy hosts" to avoid blackout). Keep the running counters of number of "resolicit-capable" ND entries and "legacy" ND entries. When it's time to send a periodic RA, look at the counters, and if the count of "legacy" hosts is zero, no need to send it. This algorithm gives multiple deployment choices: 1) "legacy" mode: set the RA interval at 1/4 of the router lifetime. This way none of the hosts ever reaches the half remaining time, resolicits will never be sent, business as usual same as today. 2) "resolicit-capable" mode: set the RA interval at 3/4 of the router lifetime. Then by this time we will have seen the RS from all the capable nodes, so we can decide whether to send a multicast RA or not. This of course needs to be worked on in order to avoid the synchronization issues (i.e. the host can not just blast an RS straight at half lifetime). But they are solvable: Assuming even the existing router lifetime limit of 2.5 hours, and RA interval of 1.5 hours, we have a space +- 0.5 hour of jitter. Taking an arbitrary guess of 180000 hosts within that /64, a uniformly distributed jitter will give ~100pps of RSs which is more than manageable. NB: this is a very first napkin sketch, so it is fairly simplistic. But I think if we were to tinker a bit more with the timers, this can be made to work. There is also a question - what happen if the router has to clean up the legacy host ND entry due to resource constraints - this can be taken care of by temporarily going into "legacy only" mode for a period of a couple of RA lifetimes. Of course, it requires the sleepy hosts to wake up every now and then. But with a lifted router lifetime limit, it will be every 9 hours. Probably doable, but let's take a SWAG just to sanity check: http://www.ti.com/lit/ds/symlink/cc3000.pdf and suppose they were one day to implement IPv6 with the similar power consumption. I count the 802.11g, because of more efficient spectrum usage. This gives us maximum power consumption of 207ma, and a shutdown current of 5ua. Now, assuming we couple it with something like http://www.atmel.com/Images/Atmel-2586-AVR-8-bit-Microcontroller-ATtiny25-ATtiny45-ATtiny85_Datasheet.pdf which has standby of 0.1ua, and 12ma of active consumption (graph at page 173 of this pdf) Let's say 20 seconds should be enough to make all the necessary 802.11 arrangements, send the data, send the solicitation, and receive advertisement. Now, assuming we power it off the typical NiMh 1.2V elements with 1800mAh capacity, the continous running time off it will be 1800*3600/220 = 29454 seconds. Let's assume for simplicity that we wake up every 8 hours, so this gives 60 seconds per day. This gives us the active life span of 490 days. Given that even the low self-discharge batteries (http://en.wikipedia.org/wiki/Nickel%E2%80%93metal_hydride_battery#Low_self-discharge_cells) have retain rate of 70%-85% within a year, probably this is a reasonable lifecycle (also for this reason I am not accounting for the standby current, it's comparable to self-discharge). This is of course also a quick napkin sketch, a properly engineered approach would take into account the 802.11 maintenance stuff - and, also it's really the "extreme" case which does not listen to the packets while asleep - so the lifetime would certainly vary - but I think this shows that this is not a totally unreasonable path. --a > > Regards, > Erik > > > From nobody Fri Feb 21 06:03:32 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135C21A01C4 for ; Fri, 21 Feb 2014 06:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04FAjOPtqwoP for ; Fri, 21 Feb 2014 06:03:30 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBA01A01C2 for ; Fri, 21 Feb 2014 06:03:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1983; q=dns/txt; s=iport; t=1392991406; x=1394201006; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=N3Ob4m37bS55BSlIaKDzUkR4kpLsUcdtkDsEm02s6QM=; b=LrFQvXf4+FVafwPlrcgEPjruAZ3VLmm8fjBg5q9GhCZ8maXwsZ3PRnnY ZxYpqU4Mp5Rkg0e4KneuzYj5wlTe70cu15Cs6rwa/cUNEpQVmig337UGC bpo/GBF6zL0q3M72VAMLfkXP83xG/4PXgmuwonJx8AdblkqqJfBeDPeZr M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFACtcB1OtJXG9/2dsb2JhbABZgwaBEsA9gQwWdIImAQEEOk8CAQgiFBAyJQIEARqHfctUF44zOIMkgRQEqluDLYIq X-IronPort-AV: E=Sophos;i="4.97,519,1389744000"; d="scan'208";a="22182598" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-7.cisco.com with ESMTP; 21 Feb 2014 14:03:26 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1LE3QAJ030650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Feb 2014 14:03:26 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 08:03:26 -0600 From: "Hemant Singh (shemant)" To: Erik Nordmark , IETF IPv6 , "Lorenzo Colitti" , "Andrew Yourtchenko (ayourtch)" Subject: RE: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Topic: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Index: AQHPLg2r7NCj0C4O60mg5b5bMD7HkJq/uMUQ Date: Fri, 21 Feb 2014 14:03:25 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89115F99A9@xmb-rcd-x06.cisco.com> References: <5305AF13.5060201@acm.org> In-Reply-To: <5305AF13.5060201@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.246.96] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/QXFCMgaqQwxLsdXFrm5bfJXBHA8 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 14:03:32 -0000 ErikN has commented on section 4.7. I have additional comments. ND as d= efined in RFC 4861 has no means to specify a prefix as off-link. Thus the = L-bit equals zero is not a valid means to signal an off-link prefix to SLAA= C hosts. ND can only specify an ipv6 destination as off-link. Here is th= e reason. The RA sets the A-bit to have hosts use SLAAC for ipv6 address a= ssignment. The router also sets the L-bit to zero in the RA. After addre= ss assignment the host has an incomplete entry in the Neighbor Cache for a = packet destination where the packet destination matches the host address up= to 64 bits. Due to the A-bit set, all addresses within the /64 assigned t= o the host are on-link. Does the host issue an address resolution NS becau= se the packet destination is on-link or due to the L-bit cleared in the rec= eived RA, the host sends the packet to the default router(s)? =20 The only means in ND to specify all destinations as off-link is to have the= RA include no PIO and have the A-bit cleared. The hosts use DHCPv6 for a= ddress assignment. This is the NBMA ND link model. The router also suppo= rts a DAD Proxy. For multicast behavior in network switches, please see RFC 4541. Additiona= lly MLD snooping is old and a burden for consumer devices to implement. N= ew protocol work is needed to mark packets for specific multicast flows so = that hosts don't have to snoop MLD.=20 Additionally, section 4.6 mentions the avalanche effect. The ND protocol r= andomizes and adds jitter when issuing messages to the link precisely to al= leviate any avalanche effect. Thus I am not convinced of the avalanche eff= ect. May I also know why the wifi nodes in a 100,000 clients link will h= ave not of entries in the Neighbor Cache? Each client talks to one or two = clients at a time. So what traffic causes the number of entries in a clien= t to be large? How large is large? Thanks, Hemant From nobody Fri Feb 21 06:18:53 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B091B1A0158 for ; Fri, 21 Feb 2014 06:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQQoNUB3KKDF for ; Fri, 21 Feb 2014 06:18:50 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4261A014D for ; Fri, 21 Feb 2014 06:18:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1695; q=dns/txt; s=iport; t=1392992326; x=1394201926; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=obr7rS0qq1MoJAluLYQ3RZOEoJq+7ODzE1iQ9R4mbKw=; b=cRzHSJfFY3eiS2UL5g2PwtFsv+Aoo1qSV1aqQ+4XfpDkePca/RSIG+uZ ujRLXZbcuddfcF6bK9W5bbRrvPDn3SWszZaVc6FT8x8jf1Q+/7kj5r/jP YE4TRzuxcDOHjneu8LsKZCCSQurH5/+Fz2LfofkDARKOgFi/2xkko5+TL 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAFxfB1OtJV2b/2dsb2JhbABagwaBEsA9gQ0WdIIsOj8SAQgOKEIlAgQBDQUbh2rLUBeOZAcChDYBA5g0kieDLYFoJB4 X-IronPort-AV: E=Sophos;i="4.97,519,1389744000"; d="scan'208";a="305706194" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 21 Feb 2014 14:18:46 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1LEIjg8007089 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Feb 2014 14:18:45 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 08:18:45 -0600 From: "Eric Levy- Abegnoli (elevyabe)" To: Ole Troan , Erik Nordmark Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Topic: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Index: AQHPLw/UGInIJGiVS0WpxpVTYyVmZw== Date: Fri, 21 Feb 2014 14:18:45 +0000 Message-ID: In-Reply-To: <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.49.80.30] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/bONy2NI6fMK3AvGi3ZXeXaWNh4c Cc: "Andrew Yourtchenko \(ayourtch\)" , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 14:18:51 -0000 DHCP won't work without changes which would be a lot bigger that anything envisioned for ND address registration. DHCP does not maintain link-locals. That would be a major change to fix that, including on hosts, since address requests are responded in unicast. DHCP does not maintain binding. It does not have the MAC (not to confuse with DUID). DHCP is not on the forwarding path where we need the information quickly Eric On 20/02/14 15:43, "Ole Troan" wrote: > > >> 4.8 seems to conflate the address assignment with DAD. Just because we >>might want to centralize the DAD checks doesn't imply that we want to >>remove the ability for the host to pick its own privacy enhanced >>interface-IDs to form its addresses. >> From a deployment perspective DHCPv6 is available for address >>assignment, but don't think we want to require that for WiFi or other >>links which have packet loss. (Packet loss occurs on wired networks as >>well, but the drop distribution is different - might happen during >>spanning tree reconvergence etc.) >> Note that DHCPv6 (RFC 3315) has a SHOULD for doing DAD on the addresses >>received from the DHCP server - needed since the server could be >>confused. > >I'd like to explore the difference between DHCP address assignment and ND >address registration a little more. >the state that is required in the network for "efficient ND", why cannot >that be created and maintained by DHCP? > >there are multiple ways of dealing with DAD in this scenario, including >solutions that don't require host changes. >DHCP also supports temporary addresses btw. > >cheers, >Ole > > From nobody Fri Feb 21 07:08:20 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1ED71A022F for ; Fri, 21 Feb 2014 07:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAEXkUOkWviZ for ; Fri, 21 Feb 2014 07:08:15 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2FD1A0179 for ; Fri, 21 Feb 2014 07:08:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3107; q=dns/txt; s=iport; t=1392995292; x=1394204892; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DaRU/fr0sFmFwaeFHKBjyp5XXOEuCCQ2cAqxPPF4KV0=; b=LXm0n/kXdYHIFEljSWKd0NnwG+bSSrWKO/qEaXREMI2zOmYhLd+Ck6+Q j0biN08ZHXnQjrJUVCD3rJE9Lf0w7Av5auf02AoQ8eucbouzI7lWreTeU q65qpWj6QMmMXbSQ3K3e6cZlm32q+M95oZNdDgswzYYjs1XLnalsWZbsF 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFANhqB1OtJV2d/2dsb2JhbABagwY7V8A9gQ4WdIIlAQEBBAEBATc0CwwEAgEIEQQBAQsUCQcnCxQJCAIEAQ0FCBOHag3LTRMEjjMGKwcCBIMegRQEqluDLYFoJB4 X-IronPort-AV: E=Sophos;i="4.97,519,1389744000"; d="scan'208";a="305596432" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 21 Feb 2014 15:08:11 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1LF8B4A007845 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Feb 2014 15:08:11 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 09:08:10 -0600 From: "Hemant Singh (shemant)" To: "Eric Levy- Abegnoli (elevyabe)" , Ole Troan , Erik Nordmark Subject: RE: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Topic: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Index: AQHPLg2r7NCj0C4O60mg5b5bMD7HkJq+nKaAgAGLfID//6ZOcA== Date: Fri, 21 Feb 2014 15:08:09 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89115F9A55@xmb-rcd-x06.cisco.com> References: <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.71.141] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/jqBYNHuePzJ-Vno19DJW_tC4noE Cc: "Andrew Yourtchenko \(ayourtch\)" , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 15:08:17 -0000 I agree with Eric. Without changing some IETF RFC's such as making sendin= g DAD a MUST for every DHCPv6 acquired address or not changing RFCs we stil= l will have to change ipv6 implementations to make DHCPv6 work. =20 For this wifi services, the client and the access-point (AP) serving the cl= ient are in the same ipv6 ND link-local domain. There are several solution= s but implementations will change.=20 A hack, but if the AP also includes DHCPv6 server, the AP knows from the up= stream L2 frame of the DHCPv6 SOLICIT as to what the client mac-address and= ipv6 link-local address is. If the DHCPv6 server is north-bound of the A= P, then the AP should support DHCPv6 relay services and the relay tracks cl= ient mac-address vs. ipv6 address(es) in the AP. =20 Hemant -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Eric Levy- Abegnoli = (elevyabe) Sent: Friday, February 21, 2014 9:19 AM To: Ole Troan; Erik Nordmark Cc: Andrew Yourtchenko (ayourtch); 6man WG Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast DHCP won't work without changes which would be a lot bigger that anything e= nvisioned for ND address registration. DHCP does not maintain link-locals. That would be a major change to fix tha= t, including on hosts, since address requests are responded in unicast. DHCP does not maintain binding. It does not have the MAC (not to = confuse with DUID). DHCP is not on the forwarding path where we need the information quickly Er= ic On 20/02/14 15:43, "Ole Troan" wrote: > > >> 4.8 seems to conflate the address assignment with DAD. Just because=20 >>we might want to centralize the DAD checks doesn't imply that we want=20 >>to remove the ability for the host to pick its own privacy enhanced=20 >>interface-IDs to form its addresses. >> From a deployment perspective DHCPv6 is available for address=20 >>assignment, but don't think we want to require that for WiFi or other=20 >>links which have packet loss. (Packet loss occurs on wired networks as=20 >>well, but the drop distribution is different - might happen during=20 >>spanning tree reconvergence etc.) Note that DHCPv6 (RFC 3315) has a=20 >>SHOULD for doing DAD on the addresses received from the DHCP server -=20 >>needed since the server could be confused. > >I'd like to explore the difference between DHCP address assignment and=20 >ND address registration a little more. >the state that is required in the network for "efficient ND", why=20 >cannot that be created and maintained by DHCP? > >there are multiple ways of dealing with DAD in this scenario, including=20 >solutions that don't require host changes. >DHCP also supports temporary addresses btw. > >cheers, >Ole > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From nobody Fri Feb 21 07:40:23 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03491A016F for ; Fri, 21 Feb 2014 07:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.598 X-Spam-Level: * X-Spam-Status: No, score=1.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_PSBL=2.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJQEQEBPBDYw for ; Fri, 21 Feb 2014 07:40:19 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0288C1A019A for ; Fri, 21 Feb 2014 07:40:05 -0800 (PST) Received: from dhcp-10-61-104-86.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 7C46C60B1; Fri, 21 Feb 2014 07:39:58 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_42B1F205-46E9-4B56-A28C-3234B3736E64"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast From: Ole Troan In-Reply-To: Date: Fri, 21 Feb 2014 16:39:56 +0100 Message-Id: <4FB6D66E-1C63-45B0-8A7E-736639A532F9@employees.org> References: To: "Eric Levy- Abegnoli (elevyabe)" X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/-aOKqgUU2NsQTKMxKsgSH9PxzKA Cc: Erik Nordmark , Andrew Yourtchenko , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 15:40:21 -0000 --Apple-Mail=_42B1F205-46E9-4B56-A28C-3234B3736E64 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Eric, > DHCP won't work without changes which would be a lot bigger that = anything > envisioned for ND address registration. can you elaborate? > DHCP does not maintain link-locals. That would be a major change to = fix > that, including on hosts, since address requests are responded in = unicast. do we need to care about link-locals? are they part of the problem we = need to solve? > DHCP does not maintain binding. It does not have the MAC = (not to > confuse with DUID). true, but an onlink DHCP server or snooping relay could do an address = discovery request to populate the ND table. > DHCP is not on the forwarding path where we need the information = quickly what do you mean by that? if the function is on the first-hop router, = then that's a deployment choice. ND register also needs to solve how to deal with multiple routers. I = believe -05 proposes that the host maintains the state in all on-link = routers, but that has quite a few implications too. cheers, Ole --Apple-Mail=_42B1F205-46E9-4B56-A28C-3234B3736E64 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 iQEbBAEBCgAGBQJTB3NMAAoJEFuJXizso86gX+AH+MNQ+y+xb5yJ9tZa34gnlYJ+ YWtyUQHfOTMtgyg3lm2yr+GmmTWjVxum/WPe7+ODDESRlqBNL5tweI6zo4RZg784 LU8nYr+d4LErzicCdTX0wAzqUXyU7BMBHHmb0t9YiNZFOZgVUQJed9UQASJCJ8e4 gpcUmLwmJb9hrpsyVqZaX3VqT/gg/RulRbA8fBvxs4/UsqGUVWfyg1sVukeL3xET ksqcO2K9uY2ezOTUdhY9yYIoqObNhxljBQ5apgBULjbDj/Ab2GJ9Vjo/ACgGTkv5 bKpeZ7bbz7Wcg5pBbXBNtqbUG7MDxRZ3Q0K/3KAJrcJZWst1e3Z1Th4blMwrbw== =SiBW -----END PGP SIGNATURE----- --Apple-Mail=_42B1F205-46E9-4B56-A28C-3234B3736E64-- From nobody Fri Feb 21 08:47:30 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836101A041B for ; Fri, 21 Feb 2014 07:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtpfIibZD7nc for ; Fri, 21 Feb 2014 07:53:30 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0AD1A01BE for ; Fri, 21 Feb 2014 07:53:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4248; q=dns/txt; s=iport; t=1392998006; x=1394207606; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=L+fwtkMUFZsaX05oWieNqLp+LEITaiuuPv8dUws2hOA=; b=mdiGiLWiXVwWvkCqMGj29nAtFbrpqtWCBc3jiukyvIoGVeD97XhnA03Q jbJuhk+i3TJ5fXiuU2dIhmpqEt3rHyvWqzB0w9/S48q4Ay24gaZBNgz5R ja+noJr5IL3kepdynTLcW+EtSmPptLJ3Hi0BwEbeKtphWeql+xGFyrhug 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFACx2B1OtJXHA/2dsb2JhbABagwaBEsA9gQ4WdIIlAQEBAwE4Aj8FCwtGSQENBg6IAgjLZBeOZAeEOASefItfgy6CKQ X-IronPort-AV: E=Sophos;i="4.97,519,1389744000"; d="scan'208";a="22208745" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-7.cisco.com with ESMTP; 21 Feb 2014 15:53:26 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1LFrPeH031249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Feb 2014 15:53:25 GMT Received: from [10.61.163.42] (10.61.163.42) by xhc-rcd-x04.cisco.com (173.37.183.78) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 21 Feb 2014 09:53:25 -0600 Date: Fri, 21 Feb 2014 16:52:50 +0100 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: "Hemant Singh (shemant)" Subject: RE: Comments on draft-yourtchenko-colitti-nd-reduce-multicast In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89115F99A9@xmb-rcd-x06.cisco.com> Message-ID: References: <5305AF13.5060201@acm.org> <75B6FA9F576969419E42BECB86CB1B89115F99A9@xmb-rcd-x06.cisco.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" X-Originating-IP: [10.61.163.42] Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/HLQt2p4jUuytx9B7_8pK0TNHg8w X-Mailman-Approved-At: Fri, 21 Feb 2014 08:47:29 -0800 Cc: Erik Nordmark , IETF IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 15:53:32 -0000 On Fri, 21 Feb 2014, Hemant Singh (shemant) wrote: > ErikN has commented on section 4.7. I have additional comments. ND >as defined in RFC 4861 has no means to specify a prefix as off-link. >Thus the L-bit equals zero is not a valid means to signal an off-link >prefix to SLAAC hosts. ND can only specify an ipv6 destination as >off-link. Here is the reason. The RA sets the A-bit to have hosts use >SLAAC for ipv6 address assignment. The router also sets the L-bit to >zero in the RA. After address assignment the host has an incomplete >entry in the Neighbor Cache for a packet destination where the packet >destination matches the host address up to 64 bits. Due to the A-bit hmm I'd be really interested to see which host implementation behaves this way. I explicitly tested Linux, MacOS X, iOS - none of them do. I glanced over the shoulder at the behavior of the Windows box - and it was behaving in a similar fashion which does not match what you describe. >set, all addresses within the /64 assigned to the host are on-link. Does RFC4861 says this: on-link - an address that is assigned to an interface on a specified link. A node considers an address to be on- link if: - it is covered by one of the link's prefixes (e.g., as indicated by the on-link flag in the Prefix Information option), or - a neighboring router specifies the address as the target of a Redirect message, or - a Neighbor Advertisement message is received for the (target) address, or - any Neighbor Discovery message is received from the address. Note - that the "on-link" flag needs to be on as well, A-bit alone does not cut it. The "off-link" shortcut of mine is unfortunate, since indeed it is not strictly speaking correct. But "Not-on-link-but-because-ICMPv6-redirects-are-disabled-it-is-treated-as-off-link" is a bit too long to write. Probably a new term is due there. >the host issue an address resolution NS because the packet destination is >on-link or due to the L-bit cleared in the received RA, the host sends >the packet to the default router(s)? L-bit set to zero and no-redirects (Thanks Erik Nordmark for the correction of this important omission in the write-up!) worked fine to have the hosts send all the packets to the default router, thus avoiding performing the ND for this destination. Of course, a better wording proposal is always welcome. > > The only means in ND to specify all destinations as off-link is to have >the RA include no PIO and have the A-bit cleared. The hosts use DHCPv6 >for address assignment. This is the NBMA ND link model. The router >also supports a DAD Proxy. > >> For multicast behavior in network switches, please see RFC 4541. Interesting read, thanks. >Additionally MLD snooping is old and a burden for consumer devices to >implement. New protocol work is needed to mark packets for specific >multicast flows so that hosts don't have to snoop MLD. The consumer switches can flood, it's not a problem there, really. > > Additionally, section 4.6 mentions the avalanche effect. The ND >protocol randomizes and adds jitter when issuing messages to the link >precisely to alleviate any avalanche effect. Thus I am not convinced of >the avalanche effect. May I also know why the wifi nodes in a 100,000 >clients link will have not of entries in the Neighbor Cache? Each client >talks to one or two clients at a time. So what traffic causes the number >of entries in a client to be large? How large is large? If you're not convinced, then you can skip this item for your deployment. I've seen it once, and there were multiple contributing factors, so I don't have a good data to convince you. Equally I don't have a spare lab with 9000 hosts of various operating systems, moving around. I left it because it does seem like a conservatively prudent thing to do. --a > > Thanks, > > Hemant > From nobody Fri Feb 21 09:08:02 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690321A0478 for ; Fri, 21 Feb 2014 09:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3uvHtKf6hzr for ; Fri, 21 Feb 2014 09:07:58 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 86DDA1A0208 for ; Fri, 21 Feb 2014 09:07:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3438; q=dns/txt; s=iport; t=1393002475; x=1394212075; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4fp/YqcI7FsqJywJpD/Lc8hO4IAkhb+zr5m0a7I4e+c=; b=Lrhy2KM+sE60I+gyR6MkYFM3jnQAwYC/w8gBrC74fOpLoxywNqGpKJ99 yeW1vRrEB0gwq9vDOd+WpcFo8IPNEySIj6JhrhKW3g0BVZhywe4QDQpfb GJrGAtEXz3L2s4I9FqnIrqss3dezhSCd+PJ4nMvelP95pcfeNUKzB891Z E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAICHB1OtJXG+/2dsb2JhbABagwaBBgy9NYMIgQ4WdIIlAQEBBDo/DAQCAQgRBAEBCxQQMhcBBQgCBA4Nh33LfBeOMzEHBoMegRQEqluDLYIq X-IronPort-AV: E=Sophos;i="4.97,520,1389744000"; d="scan'208";a="22219614" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-1.cisco.com with ESMTP; 21 Feb 2014 17:07:53 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1LH7rCR016619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Feb 2014 17:07:53 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 11:07:53 -0600 From: "Hemant Singh (shemant)" To: "Andrew Yourtchenko (ayourtch)" Subject: RE: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Topic: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Index: AQHPLg2r7NCj0C4O60mg5b5bMD7HkJq/uMUQgACJpgD//6YWsA== Date: Fri, 21 Feb 2014 17:07:52 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89115F9BAE@xmb-rcd-x06.cisco.com> References: <5305AF13.5060201@acm.org> <75B6FA9F576969419E42BECB86CB1B89115F99A9@xmb-rcd-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.71.141] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/hrzebCPgeHvxtaNIjvE9FDsevys Cc: Erik Nordmark , IETF IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 17:08:00 -0000 Andrew, I'd be happy to work with you later to work out any text when I have the ti= me. Thanks to you and Lorenzo for taking up this work. Please see in li= ne below.=20 -----Original Message----- From: Andrew Yourtchenko (ayourtch)=20 Sent: Friday, February 21, 2014 10:53 AM To: Hemant Singh (shemant) Cc: Erik Nordmark; IETF IPv6; Lorenzo Colitti Subject: RE: Comments on draft-yourtchenko-colitti-nd-reduce-multicast >hmm I'd be really interested to see which host implementation behaves this= way. I explicitly tested Linux, MacOS X, iOS - none of them do. I glanced = over the shoulder at the behavior of the Windows box - and it was >behaving= in a similar fashion which does not match what you describe. Note I pointed out an ambiguity for the host that is still compliant to the= specifications but the host forwarding model has ambiguity. For a side n= ote, RFC 5942 has deprecated the last two bullets of the on-link definition= in RFC 4861. That leaves two bullets and one is the Redirect bullet we ca= n put aside for this discussion. Then the leftover text for on-link from = RFC 4861 is as follows.=20 on-link - an address that is assigned to an interface on a specified link. A node considers an address to be on- link if: - it is covered by one of the link's prefixes (e.g., as indicated by the on-link flag in the Prefix Information option), or The definition starts with "an address that is assigned to an interface on = a specified link". This is it. Every address assigned to an interface has= a prefix length. Thus the host deems any address within that prefix lengt= h to be on-link. See also, RFC 4862 and search for "on-link" and you will = find the text related to prefix lengths. The first IPv6 implementation of = a popular host implementation actually did use this interpretation and actu= ally sent out an address resolution NS for a /64 destination matching its i= pv6 address when the host was sent an RA with no PIO. The host issued the= NS for resolving a packet destination which was no in the host Neighbor Ca= che.=20 >If you're not convinced, then you can skip this item for your deployment. = I've seen it once, and there were multiple contributing factors, so I don't= have a good data to convince you. Equally I don't have a spare lab with >9= 000 hosts of various operating systems, moving around. I left it because it= does seem like a conservatively prudent thing to do. It's not me. Each time anyone has contacted the IETF mailers such as the 6= man or the v6ops WG for an avalanche problem with IPv6 ND or DHCPv6, folks = in the WG's have replied that both ND and the DHCPv6 specifications have ra= ndomization and at least ND has an additional jitter that avoids avalanches= to cause any major problem in the ipv6 network. I have personally tested = routers with over 40,000 IPv6 clients with a router reload and did not see = avalanche issues with ND nor DHCPv6. Sorry, there was a typo in my email = that said "not" when I should have said "lot". I am interested to know w= hy one client in a 100K client deployment has lot of IPv6 entries in the cl= ient Neighbor Cache? How much is a lot? 10, 100, 1000 and how are these e= ntries populated in the client? Thanks, Hemant From nobody Fri Feb 21 09:32:39 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDC61A0204 for ; Fri, 21 Feb 2014 09:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0JNoy1ou3wd for ; Fri, 21 Feb 2014 09:32:36 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3031A01DC for ; Fri, 21 Feb 2014 09:32:36 -0800 (PST) Received: from dhcp-10-61-104-108.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 087B26195; Fri, 21 Feb 2014 09:32:28 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_DAD3A6E9-036A-4D6C-9FE4-253C40962F87"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast From: Ole Troan In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89115F99A9@xmb-rcd-x06.cisco.com> Date: Fri, 21 Feb 2014 18:32:25 +0100 Message-Id: <2730F679-46FC-416E-8DBB-D74676E637CA@employees.org> References: <5305AF13.5060201@acm.org> <75B6FA9F576969419E42BECB86CB1B89115F99A9@xmb-rcd-x06.cisco.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/ZOVlCv1Z-Dh93XHTcQ4sGrdOw7w Cc: Erik Nordmark , Andrew Yourtchenko , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 17:32:38 -0000 --Apple-Mail=_DAD3A6E9-036A-4D6C-9FE4-253C40962F87 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hemant, > The only means in ND to specify all destinations as off-link is to = have the RA include no PIO and have the A-bit cleared. The hosts use = DHCPv6 for address assignment. This is the NBMA ND link model. The = router also supports a DAD Proxy. RFC4861: Note, however, that a Prefix Information option with the on-link flag set to zero conveys no information concerning on-link determination and MUST NOT be interpreted to mean that addresses covered by the prefix are off-link. The only way to cancel a previous on-link indication is to advertise that prefix with the L-bit set and the Lifetime set to zero. The default behavior (see = Section 5.2) when sending a packet to an address for which no information is known about the on-link status of the address is to forward the packet to a default router; the effect of an unset L-flag is that all traffic is sent to the default = router. redirects can be used to indicate that the destination is = on-link. you are wrong with regards to the A-flag. and you are wrong = with regards to addresses having prefixes. that's an unfortunate short-hand we are using, but they are still = different things. an address does not have a prefix length. cheers, Ole --Apple-Mail=_DAD3A6E9-036A-4D6C-9FE4-253C40962F87 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 iQEcBAEBCgAGBQJTB42pAAoJEFuJXizso86g4CQH/R72MfCQmPas3QnizxZLNjae jpfwCHydEL5DwO0Y8U5m0wTDvp0uhMP/sJOe4SnyBNAapq7F1UUtGbkFL1ugYUZh xJ4+CsyGJfVZJ4U28pE6jchPCy17I6swvQ4II/53jdqRI3Y3OiffJUBKPFYxOYVR k55S+DYx/SlqKxP9ndXSPW/c6J0f/ZH7brt03BaLPJYAgSRiRk2X2d1q8vdawLlQ jH+nPe44lBEoI4cytK4H+hQ1D4xiEUu2igtHH/qcX3XGtCrkziYDfy593IPBIjRN YlCcksFJo7BtW2WBdJeKX8voEw1kx6GwQGlv7O4IMnhnSQWxamZS0kOCEgrFyxI= =ck// -----END PGP SIGNATURE----- --Apple-Mail=_DAD3A6E9-036A-4D6C-9FE4-253C40962F87-- From nobody Fri Feb 21 09:35:12 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9131A0540 for ; Fri, 21 Feb 2014 09:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4efYzmBy1_eJ for ; Fri, 21 Feb 2014 09:35:07 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id D5BCF1A022A for ; Fri, 21 Feb 2014 09:35:07 -0800 (PST) Received: from dhcp-10-61-104-108.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 03A0361C6; Fri, 21 Feb 2014 09:35:01 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_178D6FF7-480D-4C85-A1C7-EC96CDC8A636"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast From: Ole Troan In-Reply-To: <4FB6D66E-1C63-45B0-8A7E-736639A532F9@employees.org> Date: Fri, 21 Feb 2014 18:34:58 +0100 Message-Id: References: <4FB6D66E-1C63-45B0-8A7E-736639A532F9@employees.org> To: "Eric Levy- Abegnoli (elevyabe)" X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/6fHidymvMdEMsm7jWpxVKt98aTc Cc: Erik Nordmark , Andrew Yourtchenko , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 17:35:10 -0000 --Apple-Mail=_178D6FF7-480D-4C85-A1C7-EC96CDC8A636 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii and just to be clear: me engaging in this debate with regards to ND register vs DHCP should in = no way be interpreted that I agree that the solution to the problem = (we're still working on defining), is a stateful ND table. ;-) cheers, Ole without hats. On 21 Feb 2014, at 16:39 , Ole Troan wrote: > Eric, >=20 >> DHCP won't work without changes which would be a lot bigger that = anything >> envisioned for ND address registration. >=20 > can you elaborate? >=20 >> DHCP does not maintain link-locals. That would be a major change to = fix >> that, including on hosts, since address requests are responded in = unicast. >=20 > do we need to care about link-locals? are they part of the problem we = need to solve? >=20 >> DHCP does not maintain binding. It does not have the MAC = (not to >> confuse with DUID). >=20 > true, but an onlink DHCP server or snooping relay could do an address = discovery request to populate the ND table. >=20 >> DHCP is not on the forwarding path where we need the information = quickly >=20 > what do you mean by that? if the function is on the first-hop router, = then that's a deployment choice. > ND register also needs to solve how to deal with multiple routers. I = believe -05 proposes that the host maintains the state in all on-link = routers, but that has quite a few implications too. >=20 > cheers, > Ole > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_178D6FF7-480D-4C85-A1C7-EC96CDC8A636 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 iQEbBAEBCgAGBQJTB45DAAoJEFuJXizso86gp48H9RuTAp1OqQMPIiGz9S1Wd8ow vRq/G6kEcv4Vyg2aNIAx1hoRp5urbSwTjz5A1tk3gUUoQGV23UUvGIT4pAb+kc46 v8ExFma3Q0a1DdyPXi+0Dlmky0g2aJyaugo8yb+QTzvXLrKdQJUYxOr9lIW0P1UV uLuSR/PtuFQsXUVtwUc5C9EWLqd5yrOtpvZ78Hf5cpOZpQGMnvXAarqxPATmynNN SmOyB4jAqq0lTDSsW9zMsp09p5tPTTVzjNFpYkFjbg63A0BIVu/+YlKo7vsh+GKJ i6gxGZoCR/gfnXV2Vgtoc2hl56QGSSof2n5qkYk9B8GPHu/aoNW88W7O3Ol+CQ== =KD4/ -----END PGP SIGNATURE----- --Apple-Mail=_178D6FF7-480D-4C85-A1C7-EC96CDC8A636-- From nobody Fri Feb 21 09:36:11 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3A21A02D0 for ; Fri, 21 Feb 2014 09:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.449 X-Spam-Level: X-Spam-Status: No, score=-14.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcdPZdhtoAMl for ; Fri, 21 Feb 2014 09:36:07 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 433B61A01DC for ; Fri, 21 Feb 2014 09:36:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1857; q=dns/txt; s=iport; t=1393004163; x=1394213763; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=579rvkZFcqwXOaOZT084DAPd+/ZPHz8nrLoherpOeSM=; b=RVy6dc11thydVGikl+11FH+mtwk/KxuKF1Pd1+L8DNHfQyg9q5j0VRMw j/Uz8CkqQ6FMMkOA3qGp5WqbFhdYWNoVqaOMgehxK15VYpl68AG8YNe26 Ldvu0IvBFx9NJ3NVvqhUyhUo/nrBBaMTTSweNzCK4J2e6MWo96wWmm/Rt o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGSNB1OtJXG//2dsb2JhbABagwaBEsA9gQ4WdIIlAQEBAwE6PxIBCA4oQiUCBA4Fh30Iy3gXjmQHAoQ2BJg0kieDLYIq X-IronPort-AV: E=Sophos;i="4.97,520,1389744000"; d="scan'208";a="305693094" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 21 Feb 2014 17:36:03 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1LHa3NF002909 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Feb 2014 17:36:03 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 11:36:02 -0600 From: "Eric Levy- Abegnoli (elevyabe)" To: Ole Troan Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Topic: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Index: AQHPLytjGInIJGiVS0WpxpVTYyVmZw== Date: Fri, 21 Feb 2014 17:36:02 +0000 Message-ID: In-Reply-To: <4FB6D66E-1C63-45B0-8A7E-736639A532F9@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.49.80.30] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/LVaQAvafwvGGcX-z5w7hoDVAvik Cc: Erik Nordmark , "Andrew Yourtchenko \(ayourtch\)" , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 17:36:09 -0000 Ole, On 21/02/14 16:39, "Ole Troan" wrote: >Eric, > >> DHCP won't work without changes which would be a lot bigger that >>anything >> envisioned for ND address registration. > >can you elaborate? This is exactly what I did below :) Adding link-local support in DHCP would require to change quite substancially the flows to bootstrap the first address, when the host has none yet. Managing bindings requires to collect the information (as I said some bits are missing today), maintain it, and serve it. That implies more changes. > >> DHCP does not maintain link-locals. That would be a major change to fix >> that, including on hosts, since address requests are responded in >>unicast. > >do we need to care about link-locals? are they part of the problem we >need to solve? Yes we do. They are about half the problem, an't they? More if most traffic is local to the link. Less otherwise. > >> DHCP does not maintain binding. It does not have the MAC (not >>to >> confuse with DUID). > >true, but an onlink DHCP server or snooping relay could do an address >discovery request to populate the ND table. I will not claim it cannot be done with DHCP. With changes. Like it could be done with 10 others protocols storing and distributing addresses. It just sound more difficult to do it there rather than in the place & module where you already manage bindings. Eric =20 > >> DHCP is not on the forwarding path where we need the information quickly > >what do you mean by that? if the function is on the first-hop router, >then that's a deployment choice. >ND register also needs to solve how to deal with multiple routers. I >believe -05 proposes that the host maintains the state in all on-link >routers, but that has quite a few implications too. > >cheers, >Ole From nobody Fri Feb 21 10:57:05 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950F91A0224 for ; Fri, 21 Feb 2014 10:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAUFSAsYA7VH for ; Fri, 21 Feb 2014 10:57:02 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 965CB1A0534 for ; Fri, 21 Feb 2014 10:57:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1619; q=dns/txt; s=iport; t=1393009017; x=1394218617; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tOrLMdUFRaf9uLF5QA4M3vsBUJGj422PFGo3apzvWqY=; b=B31rqboPryWFfYl/gcmPr3IBvtgef1o1PyS80RChJcQ2EG/GxbExAhzv HKV+ivOT52u1z13axTsQPUWAWDLN29Z42T6XaBhssRJVZWhFS+iKiD7ih 82N2+QnsWn+BZ9qaRC4YsHjIi/uQYx4e6pgW1A95zuKk8jW2xYlQTczmd E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFANmgB1OtJV2d/2dsb2JhbABagwaBEsA9gQ8WdIIlAQEBBDo/DAQCAQgOAwQBAQsUCQcyFAkIAgQOBQiHfctBF44zMQcGgx6BFAEDqluDLYIq X-IronPort-AV: E=Sophos;i="4.97,520,1389744000"; d="scan'208";a="305763658" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 21 Feb 2014 18:56:56 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1LIuuL6026634 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Feb 2014 18:56:56 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 12:56:56 -0600 From: "Hemant Singh (shemant)" To: Ole Troan Subject: RE: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Topic: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Index: AQHPLg2r7NCj0C4O60mg5b5bMD7HkJq/uMUQgACleYD//7AWIA== Date: Fri, 21 Feb 2014 18:56:55 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89115F9CC5@xmb-rcd-x06.cisco.com> References: <5305AF13.5060201@acm.org> <75B6FA9F576969419E42BECB86CB1B89115F99A9@xmb-rcd-x06.cisco.com> <2730F679-46FC-416E-8DBB-D74676E637CA@employees.org> In-Reply-To: <2730F679-46FC-416E-8DBB-D74676E637CA@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.71.141] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/b13quf8r-j8F8zPo_OjrW_H04Tc Cc: Erik Nordmark , "Andrew Yourtchenko \(ayourtch\)" , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 18:57:03 -0000 Ole, -----Original Message----- From: Ole Troan [mailto:otroan@employees.org]=20 Sent: Friday, February 21, 2014 12:32 PM To: Hemant Singh (shemant) Cc: Erik Nordmark; 6man WG; Lorenzo Colitti; Andrew Yourtchenko (ayourtch) Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast >RFC4861: > Note, however, that a Prefix Information option > with the on-link flag set to zero conveys no information concerning > on-link determination and MUST NOT be interpreted to mean that > addresses covered by the prefix are off-link. =20 The RA has the A-bit set and the L-bit cleared. So as per the specificatio= n text above the L-bit is zero and the host does not get any on/off--link d= etermination from the L-bit for the addresses covered by the prefix in the = PIO. The host configures its ipv6 address from the PIO in the RA using SL= AAC. Now the host has to send a packet out an interface and the packet des= tination in the host's Neighbor Cache. The packet destination also matches= the host's prefix to a /64. So what does the host do? =20 Issue=20 (a) an address resolution NS (assuming the destination is on-link) due to S= LAAC operation. or (b) send the packet to the default router(s). The L-bit has conveyed no on= - or off-link information. So doesn't the host resort to (a) above. If th= e host choses to go to operation (b) what signaled to the host that the des= tination is off-link? If the host picked (a), why is that? If you can't determine one concrete choice from the two above, we have an a= mbiguity.=20 Hemant =20 From nobody Fri Feb 21 11:24:44 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF49D1A0561 for ; Fri, 21 Feb 2014 11:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATScFQIyHbgp for ; Fri, 21 Feb 2014 11:24:41 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD841A054A for ; Fri, 21 Feb 2014 11:24:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2517; q=dns/txt; s=iport; t=1393010678; x=1394220278; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jj9jbN0Iuh1bhs5Lts4Evm3/RuE0ptrZNdo7uBWddoc=; b=N7V/Pum76n7wGY0Dp2Vk9y2HYVDIBHFmWYjD6RLfdMnJRZJonM5INIre Lb9B+boyRyWfwb9qM5c0LMH6xV8JAWKTQJbr50MhEVriyComsTr6Psahh 1BhjyZThqQjt6S8tfg3A2whFScV4qeGVCJDhMYMiFlGQSSHwa9QEJLmGl k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAMenB1OtJV2Y/2dsb2JhbABagwY7V8A9gQ8WdIIlAQEBBAEBATc0CwwEAgEIDgMEAQELFAkHJwsUCQgCBA4FCId9DcsfEwSOMzEHBoMegRQEqluDLYIq X-IronPort-AV: E=Sophos;i="4.97,520,1389744000"; d="scan'208";a="305684422" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 21 Feb 2014 19:24:37 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1LJOb9s025711 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Feb 2014 19:24:37 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 13:24:37 -0600 From: "Hemant Singh (shemant)" To: Ole Troan Subject: RE: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Topic: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Index: AQHPLg2r7NCj0C4O60mg5b5bMD7HkJq/uMUQgACleYD//7AWIIAACkvA Date: Fri, 21 Feb 2014 19:24:36 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89115F9D68@xmb-rcd-x06.cisco.com> References: <5305AF13.5060201@acm.org> <75B6FA9F576969419E42BECB86CB1B89115F99A9@xmb-rcd-x06.cisco.com> <2730F679-46FC-416E-8DBB-D74676E637CA@employees.org> <75B6FA9F576969419E42BECB86CB1B89115F9CC5@xmb-rcd-x06.cisco.com> In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89115F9CC5@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.78.102] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/BkXXwqchWnilE4WtUWTYyfDkPh0 Cc: Erik Nordmark , "Andrew Yourtchenko \(ayourtch\)" , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 19:24:43 -0000 Sigh and humble apologies. One typo in my email below.=20 Change=20 Now the host has to send a packet out an interface and the packet destinati= on in the host's Neighbor Cache To Now the host has to send a packet out an interface and the packet destinati= on is NOT in the host's Neighbor Cache Thanks, Hemant -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Hemant Singh (sheman= t) Sent: Friday, February 21, 2014 1:57 PM To: Ole Troan Cc: Erik Nordmark; Andrew Yourtchenko (ayourtch); 6man WG Subject: RE: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Ole, -----Original Message----- From: Ole Troan [mailto:otroan@employees.org]=20 Sent: Friday, February 21, 2014 12:32 PM To: Hemant Singh (shemant) Cc: Erik Nordmark; 6man WG; Lorenzo Colitti; Andrew Yourtchenko (ayourtch) Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast >RFC4861: > Note, however, that a Prefix Information option > with the on-link flag set to zero conveys no information concerning > on-link determination and MUST NOT be interpreted to mean that > addresses covered by the prefix are off-link. =20 The RA has the A-bit set and the L-bit cleared. So as per the specificatio= n text above the L-bit is zero and the host does not get any on/off--link d= etermination from the L-bit for the addresses covered by the prefix in the = PIO. The host configures its ipv6 address from the PIO in the RA using SL= AAC. Now the host has to send a packet out an interface and the packet des= tination in the host's Neighbor Cache. The packet destination also matches= the host's prefix to a /64. So what does the host do? =20 Issue=20 (a) an address resolution NS (assuming the destination is on-link) due to S= LAAC operation. or (b) send the packet to the default router(s). The L-bit has conveyed no on= - or off-link information. So doesn't the host resort to (a) above. If th= e host choses to go to operation (b) what signaled to the host that the des= tination is off-link? If the host picked (a), why is that? If you can't determine one concrete choice from the two above, we have an a= mbiguity.=20 Hemant =20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From nobody Fri Feb 21 11:37:58 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FD61A05A6 for ; Fri, 21 Feb 2014 11:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1w6c_2yqHdv for ; Fri, 21 Feb 2014 11:37:52 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id E82711A05B3 for ; Fri, 21 Feb 2014 11:37:30 -0800 (PST) Received: from dhcp-10-61-103-160.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 EFA8260C4; Fri, 21 Feb 2014 11:37:23 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_78B419FD-756B-4062-A390-F287A90CD8F9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast From: Ole Troan In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89115F9CC5@xmb-rcd-x06.cisco.com> Date: Fri, 21 Feb 2014 20:37:20 +0100 Message-Id: <1CB2CA70-30E3-4B47-B0BC-5B80A41FEAD2@employees.org> References: <5305AF13.5060201@acm.org> <75B6FA9F576969419E42BECB86CB1B89115F99A9@xmb-rcd-x06.cisco.com> <2730F679-46FC-416E-8DBB-D74676E637CA@employees.org> <75B6FA9F576969419E42BECB86CB1B89115F9CC5@xmb-rcd-x06.cisco.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/hNytUjcb8WwEYDCCEk_LCLyuDes Cc: Erik Nordmark , Andrew Yourtchenko , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 19:37:54 -0000 --Apple-Mail=_78B419FD-756B-4062-A390-F287A90CD8F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hemant, we are severely digressing here, but since it is Friday... > The RA has the A-bit set and the L-bit cleared. So as per the = specification text above the L-bit is zero and the host does not get any = on/off--link determination from the L-bit for the addresses covered by = the prefix in the PIO. The host configures its ipv6 address from the = PIO in the RA using SLAAC. Now the host has to send a packet out an = interface and the packet destination in the host's Neighbor Cache. The = packet destination also matches the host's prefix to a /64. So what = does the host do? =20 >=20 > Issue=20 >=20 > (a) an address resolution NS (assuming the destination is on-link) due = to SLAAC operation. >=20 > or >=20 > (b) send the packet to the default router(s). The L-bit has conveyed = no on- or off-link information. So doesn't the host resort to (a) = above. If the host choses to go to operation (b) what signaled to the = host that the destination is off-link? If the host picked (a), why is = that? >=20 > If you can't determine one concrete choice from the two above, we have = an ambiguity.=20 there is no ambiguity. see the conceptual sending algorithm in section = 5.2, RFC4861. a prefix with the L flag =3D 0 is not added to the Prefix List. if the = Prefix List is empty all packets will be sent to the default router, = apart from packets destined to fe80::/10. cheers, Ole --Apple-Mail=_78B419FD-756B-4062-A390-F287A90CD8F9 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 iQEcBAEBCgAGBQJTB6rwAAoJEFuJXizso86gBTUH/0jOrc89OcESxRxi23oBnJx6 itrnBo6fd/7E5FS4+8HjI+blPhJce/7y2bl0j0kkQ3qd6mzhbOtyIPyPyaWcCPNp D/Wzf6xMdpVIdH4ITElthobhbuM4m/beCqbca0uibhqxXwXg+M/jK+RhhUWnhv7J rzJ1og9YXGuUz+jHl5wGbvQKMJNLhC+flCkDkXgR5TgdfztVJHpWxFi/tKCgvZDK QOqdKrTqJaDv+h+dbbTqWz096/3LY5QvVho911Rt+/+kSY/QHQvsNssoDUL7BUoO q0WFXRrX773mCflBRBzyDeyhXkoeB1d2oSrjOqwT2Dnmc7BGluFd+EOa+EKw3EA= =opXg -----END PGP SIGNATURE----- --Apple-Mail=_78B419FD-756B-4062-A390-F287A90CD8F9-- From nobody Fri Feb 21 12:07:10 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1506A1A051D for ; Fri, 21 Feb 2014 12:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ey_lkS_0Pr8u for ; Fri, 21 Feb 2014 12:07:04 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id A30861A026C for ; Fri, 21 Feb 2014 12:07:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1099; q=dns/txt; s=iport; t=1393013220; x=1394222820; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7SpyMUyuAOvblhQyQ/D2zrsFjA0BfxDnfp1fAs3OizU=; b=NeMRBDbQVq4XAM6ehXzYLkZ6c64KF+tZvcyncAFs/5ZPG8eqvzInnhCS c/rLpAPGVhhjWPg7vy84Sh0JTfKw3xvuV4cDe4k7jz9HOwRUrmDpF/fLf baEsNlFWSoQ+M+RPVhTI61RcjTZXJqwRN4n+Si3/ulkLKPk2Z+Ygtg8n8 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAK6wB1OtJXG8/2dsb2JhbABagwaBEsBBgRAWdIIlAQEBBDo/DAQCAQgOAwQBAQsUCQcyFAkIAgQOBQiHfcskF44zMQcGgx6BFAEDqluDLYIq X-IronPort-AV: E=Sophos;i="4.97,520,1389744000"; d="scan'208";a="22265245" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-6.cisco.com with ESMTP; 21 Feb 2014 20:06:59 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1LK6xk1005450 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Feb 2014 20:06:59 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 14:06:59 -0600 From: "Hemant Singh (shemant)" To: Ole Troan Subject: RE: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Topic: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Index: AQHPLg2r7NCj0C4O60mg5b5bMD7HkJq/uMUQgACleYD//7AWIIAActEA//+id5A= Date: Fri, 21 Feb 2014 20:06:58 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89115F9DCF@xmb-rcd-x06.cisco.com> References: <5305AF13.5060201@acm.org> <75B6FA9F576969419E42BECB86CB1B89115F99A9@xmb-rcd-x06.cisco.com> <2730F679-46FC-416E-8DBB-D74676E637CA@employees.org> <75B6FA9F576969419E42BECB86CB1B89115F9CC5@xmb-rcd-x06.cisco.com> <1CB2CA70-30E3-4B47-B0BC-5B80A41FEAD2@employees.org> In-Reply-To: <1CB2CA70-30E3-4B47-B0BC-5B80A41FEAD2@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.71.141] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/LCVW6L_9oJ9cAgTIx37nEzF9ffI Cc: Erik Nordmark , "Andrew Yourtchenko \(ayourtch\)" , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 20:07:06 -0000 Ole, -----Original Message----- From: Ole Troan [mailto:otroan@employees.org]=20 Sent: Friday, February 21, 2014 2:37 PM To: Hemant Singh (shemant) Cc: Erik Nordmark; 6man WG; Lorenzo Colitti; Andrew Yourtchenko (ayourtch) Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast >there is no ambiguity. see the conceptual sending algorithm in section 5.2= , RFC4861. >a prefix with the L flag =3D 0 is not added to the Prefix List. if the Pre= fix List is empty all packets will be sent to the default router, apart fro= m packets destined to fe80::/10. Thanks for this clarification - agreed. Without any specific rules, if co= nceptually one thinks about ARP and ND and deems the default is off-link, t= hen the decisions are very simple. The algorithm for either ipv4 or ipv6 i= s deterministic in that if the algorithm cannot make a clear on-link determ= ination, the algorithm defaults to off-link which implies sending traffic t= o the default router(s). Only when clear indication of on-link exists, an = address resolution NS is issued. Hemant From nobody Fri Feb 21 12:38:25 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BECD1A023F for ; Fri, 21 Feb 2014 12:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Of_4AKcT7Xnl for ; Fri, 21 Feb 2014 12:38:18 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id AEAB91A0242 for ; Fri, 21 Feb 2014 12:38:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8141; q=dns/txt; s=iport; t=1393015095; x=1394224695; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=QYFRlqg0H+NRW5FuX2xGI3s2CT/2MJ6/LZmNP5ZAYJE=; b=g3no5ceAKhRs8D0kAu5Ez30hhiKjqwe4r6N3z2NfKz1D9DbqTk41tqKd SKoXCJtgkMPid2qkn0E2xk98LlZcwwcUstEp72c79lEIWBspopzOMdDoR V+lopD8GSAhBDoqlKuXMdSR9duxk69gQVyKka8trFQ/jAHf18swvVV4NC I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAL24B1OtJXHB/2dsb2JhbABSCIMGgRLAQYEQFnSCJQEBAQMBJxECNgkQC0ZXBg6IAgjLKBeODAJWB4Q4BJRJijOLX4MugWdC X-IronPort-AV: E=Sophos;i="4.97,520,1389744000"; d="scan'208";a="22282642" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-8.cisco.com with ESMTP; 21 Feb 2014 20:38:14 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1LKcEpl005480 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Feb 2014 20:38:14 GMT Received: from [10.61.173.41] (10.61.173.41) by xhc-rcd-x03.cisco.com (173.37.183.77) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 21 Feb 2014 14:38:08 -0600 Date: Fri, 21 Feb 2014 21:36:46 +0100 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: "Hemant Singh (shemant)" Subject: RE: Comments on draft-yourtchenko-colitti-nd-reduce-multicast In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89115F9BAE@xmb-rcd-x06.cisco.com> Message-ID: References: <5305AF13.5060201@acm.org> <75B6FA9F576969419E42BECB86CB1B89115F99A9@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89115F9BAE@xmb-rcd-x06.cisco.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" X-Originating-IP: [10.61.173.41] Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/N4dozyIzaOBzzm95qaWDZ30p1os Cc: Erik Nordmark , IETF IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 20:38:23 -0000 Hemant, On Fri, 21 Feb 2014, Hemant Singh (shemant) wrote: >> If you're not convinced, then you can skip this item for your >>deployment. I've seen it once, and there were multiple contributing >>factors, so I don't have a good data to convince you. Equally I don't >>have a spare lab with >9000 hosts of various operating systems, moving >>around. I left it because it does seem like a conservatively prudent >>thing to do. > > It's not me. Each time anyone has contacted the IETF mailers such as >the 6man or the v6ops WG for an avalanche problem with IPv6 ND or DHCPv6, >folks in the WG's have replied that both ND and the DHCPv6 specifications >have randomization and at least ND has an additional jitter that avoids >avalanches to cause any major problem in the ipv6 network. I have >personally tested routers with over 40,000 IPv6 clients with a router Were they 802.11 clients ? Wireless medium does have different properties. Did you make any "flash failure" events ? Anyway, see below. >reload and did not see avalanche issues with ND nor DHCPv6. Sorry, >there was a typo in my email that said "not" when I should have said >"lot". I am interested to know why one client in a 100K client >deployment has lot of IPv6 entries in the client Neighbor Cache? How >much is a lot? 10, 100, 1000 and how are these entries populated in the >client? Myself I did not like this portion of my reply with no quantifiable data (because operating on a basis of a belief is not a good engineering). I happened to have a couple of hours of offline time, during which I tried to sketch the scenario and try to get as far as I can without building a lab. It's a *very rough sketch*. If you think there can be parts that can be made better in it, tell me. The initial assumptions for this thought experiment are as follows: 1) We have 10000 clients in a single /64. 2) There are multiple APs that bridge the traffic from wired onto wireless medium, with the client count limited to 100 per AP. 3) there is 20x speed difference between unicast transmission and multicast transmission.: the effective multicast speed is assumed to be 1 mbps, the effective unicast speed is assumed to be 20mbps data rate. 4) The APs are assumed to be "Naive" i.e. they do not perform any snooping nor multicast->unicast conversions, but at the same time they are able to bridge the unicast traffic without flooding it between multiple access points. I.e. we assume a model where we have a single router (or an FHRP pair) and a set of 100 APs bridging the traffic. (Corollary from the above: The effective unicast capacity is 100*20mbps, whereas the effective multicast capacity is 1*1Mbps, therefore the difference in throughput is 1000-fold). Let's first consider the steady state. Suppose each host downloads a file at 0.1 mbps. Within each AP, therefore we have a 50% capacity utilization (0.1*100 = 10Mbps, we have 20 Mbps capacity). It's easy to see this comfortably accomodates all the hosts. Obviuously the unicast NUD in this traffic is fairly minimal, so I don't think it's even worth to count how much it is. Now, lets look at a potential failure. At the time of the NUD probe, it's enough to lose the 3 retries, spaced 1 second apart. The default reachable time is 30 seconds, with the random jitter of 0.5 of that. So, all that is needed to achieve a mass NUD failure is a ~30 second outage during the period when all the hosts are sending the traffic. A reboot of the majority of the networking gear takes several times longer than this. Therefore, a crash of the default gateway during the peak hour is a one guaranteed trigger for this to happen. So, now we have a situation of 10000 hosts which have deleted their default gateway from the neighbor table, and send the multicast neighbor solicitations for it. Assume the NS is 64 bytes, 10000 hosts sending such a packet means 64 bytes * 8 bit * 10000 hosts = 5120000 bits/sec - or, 5 mbps. Note, that this is only the shared bandwidth downstream back to the hosts - the airtime spent by the upstream traffic is 20x faster, so I am gratuitously discarding it. Since the APs can not send the traffic at this rate, obviously, we will need to drop some of it. Note, if the clients succeed with the ND to the default gateway, they will start streaming data again, so the effective multicast throughput will drop to the 0.5 mbps as soon as the noticeable portion of clients recovers. Let's assume the best case of 20% of the clients managing to recover within the first second. As we are approaching full recovery, the lesser number of clients will be able to get their multicast NS sent because the airtime is being taken by the payload traffic. Anyway, let's discard that and assume that every second 20% of the clients will recover. This means that the recovery of the full set of the clients in this conditions will take an *absolute* minimum of 5 seconds. Did I prove myself wrong ? Seems so. We can see that with some of the relaxed assumptions I took, the hosts seem to recover. But, let's add to this a little bit of mDNS, and other multicast-loving protocols, which tend to generate a fair chunk of traffic when they detect the network was "restored". This can shrink the available capacity several times. Add to this that the host does not necessarily stream at 100kbps, but might have higher data rates, and I think we can consider the available multicast capacity at startup to be 1/10th of what it is in theory. This is where the things may become interesting - 1/10th of the capacity means that it will take not 5, but 50 seconds for all the hosts to recover. This means that the hosts which recovered in the very first second, will already be sending NUD traffic while the network is still under stress. If these packets are lost, the hosts might back into the pool of the "orphans" who are sending the multicast, because they delete their neighbor entry. There are some other things to consider: - I deliberately kept the scenario here with *one* ND entry. Assuming your hosts are talking with 3-4 other hosts besides the default gateway. This increases the load and proportionally makes the dangerous state easier to achieve. - another factor that I am omitting - that such a storm of ND onto the default gateway might cause rate-limiting of the control plane packets on the gateway. With some of the limits being as low as 1000pps, this might give a recovery time on the order of minutes even without the wireless multicast being the bottleneck, yet still resulting in a lot of multicast NS in the air still during the slow recovery. This is about as precise of the construct I can build. Is it perfect ? No, by no means. It also does assume that in the case of the default gateway the wireless performance will be limiting factor - I think it won't - so it's more of an appropriate scenario for a case of a p2p communications on the network. The default-gateway-only will be inherently much more stable, I think - because the multicast on the wired side is fast, so the drops on the wireless side will not matter. It's probably worth it to change the text into "There is potential for the failing NUD to *contribute* to a longer recovery and possible creation of the locked situation in the case of flash failure - but the exact quantification of the impact in such an environment is a topic of further study". And then maybe I could dump the above thought experiment into a separate draft, to see if the folks could contribute to the experiment / maybe someone could run it - and reference it in this item ? It seems like an interesting area to dig a bit more in - creating a suitable model and playing with the parameters to see where it breaks seems like a useful exercise to understand how many hosts can there be in a single /64 on WiFi with a "naive" set of access-points. Thoughts ? --a From nobody Fri Feb 21 13:22:32 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBC11A028C for ; Fri, 21 Feb 2014 13:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7p1Edjm5ROy for ; Fri, 21 Feb 2014 13:22:29 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9941A027E for ; Fri, 21 Feb 2014 13:22:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=769; q=dns/txt; s=iport; t=1393017745; x=1394227345; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=maCCwELJZFYN3+c3NqiFdUZF2DfG44W7MeuEiOlcN1g=; b=IhKmVMdIjT5YOA9jBMoHHiS60pH24m+D0rDmqgFwIdzbIlV+vNM9vgfO GpayqH8dFEmVLuD3rJ9mlysvM3y/qe64n0JkaYC3LPQ+1dEPoYC0ozMzQ 2u11G/w6CJLKD0Q8LVhFUOq122LfFTXpYqyuvF0siVlFuGDf0zlR58uDP s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAJHCB1OtJXG+/2dsb2JhbABagwaBEsA/gRAWdIImAQEEOj8QAgEIDhQUEDIlAgQODYd9y0wXjjMxB4MkgRQBA6pbgy2CKg X-IronPort-AV: E=Sophos;i="4.97,520,1389744000"; d="scan'208";a="305714739" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 21 Feb 2014 21:22:24 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1LLMOQe015943 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Feb 2014 21:22:24 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 15:22:23 -0600 From: "Hemant Singh (shemant)" To: Ole Troan Subject: RE: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Topic: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Index: AQHPLg2r7NCj0C4O60mg5b5bMD7HkJq/uMUQgACleYD//7AWIIAActEA//+2lwA= Date: Fri, 21 Feb 2014 21:22:23 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89115F9E86@xmb-rcd-x06.cisco.com> References: <5305AF13.5060201@acm.org> <75B6FA9F576969419E42BECB86CB1B89115F99A9@xmb-rcd-x06.cisco.com> <2730F679-46FC-416E-8DBB-D74676E637CA@employees.org> <75B6FA9F576969419E42BECB86CB1B89115F9CC5@xmb-rcd-x06.cisco.com> <1CB2CA70-30E3-4B47-B0BC-5B80A41FEAD2@employees.org> In-Reply-To: <1CB2CA70-30E3-4B47-B0BC-5B80A41FEAD2@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/b3vnnNxxu07aJ1jAZv66-2Y8ILY Cc: Erik Nordmark , "Andrew Yourtchenko \(ayourtch\)" , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 21:22:31 -0000 Andrew/Lorenzo, Separate thought for section 4.7 since the L-bit cleared contention is reso= lved. Section 4.7 has got to mention Redirect since the section has asked = hosts to send traffic to the default router. Since I got the Redirect tho= ught, I went back to Erik Nordmark's review and he also mentions Redirect. = However, my point is different. Section 4.7 needs to add text that "the= router is configured to not to issue any Redirects for an IPv6 destination= covered by the prefixes the router advertised in the RA with the L-bit cle= ared". To keep the router configuration and internals simple, we can even= go more restrictive in that text can say, "the router is configured to not= issue any Redirects".=20 Thanks, Hemant From nobody Fri Feb 21 13:27:59 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F961A02D7 for ; Fri, 21 Feb 2014 13:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmoPfB6jy9EV for ; Fri, 21 Feb 2014 13:27:55 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 224531A029B for ; Fri, 21 Feb 2014 13:27:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1437; q=dns/txt; s=iport; t=1393018071; x=1394227671; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CzV9ZLjT4k8prEnulDhrdFK6pS1sFjDakYoiYJrfaeE=; b=LpnjtRuPw8y3jSjoaG5lNpwruiMicDUzwp3sfvOqbb3so+t2bnJXopTT 2rPhiv+UISV/1H1ZQfX2ArdyUTSF7XER9GAZI/uHu1eC0MhGJcBHXf3xs i/rC3PLZf2wx4LssU40096fh11fYOMPIvPW46vriYL3Sc+QYHhHNaq3x5 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAMLDB1OtJV2d/2dsb2JhbABagwaBEsA/gRAWdIIlAQEBBDo/DAQCAQgRBAEBCxQJBzIUCQgCBAENBQiHfctRF44zBisHAgSDHoEUAQOqW4Mtgio X-IronPort-AV: E=Sophos;i="4.97,520,1389744000"; d="scan'208";a="305704562" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 21 Feb 2014 21:27:51 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1LLRog8029472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Feb 2014 21:27:50 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 15:27:50 -0600 From: "Hemant Singh (shemant)" To: "Eric Levy- Abegnoli (elevyabe)" , Ole Troan , Erik Nordmark Subject: RE: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Topic: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Index: AQHPLg2r7NCj0C4O60mg5b5bMD7HkJq+nKaAgAGLfICAABIUkA== Date: Fri, 21 Feb 2014 21:27:49 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89115F9EA5@xmb-rcd-x06.cisco.com> References: <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/EPhlAQXN3yLvfaC1PbGMcbmf_TU Cc: "Andrew Yourtchenko \(ayourtch\)" , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 21:27:57 -0000 RFC 3315 came into being before RFC 4862. RFC 4862 has a MUST clause for n= odes to perform DAD for DHCPv6 addresses. So shouldn't DHCPv6 clients comp= ly with RFC 4862 for DAD behavior and ignore the SHOULD for performing DAD = in RFC 3315? This is the text from RFC 4862. [Duplicate Address Detection MUST be performed on all unicast addresses pri= or to assigning them to an interface, regardless of whether they are obtain= ed through stateless autoconfiguration, DHCPv6, or manual configuration,] There is a set of exceptions to the above clause in RFC 4862 but those exce= ptions do not overrule what has been asked of DHCPv6 above for DAD.=20 Hemant -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Eric Levy- Abegnoli = (elevyabe) Sent: Friday, February 21, 2014 9:19 AM To: Ole Troan; Erik Nordmark Cc: Andrew Yourtchenko (ayourtch); 6man WG Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast DHCP won't work without changes which would be a lot bigger that anything e= nvisioned for ND address registration. DHCP does not maintain link-locals. That would be a major change to fix tha= t, including on hosts, since address requests are responded in unicast. DHCP does not maintain binding. It does not have the MAC (not to = confuse with DUID). DHCP is not on the forwarding path where we need the information quickly Er= ic From nobody Fri Feb 21 15:22:39 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899301A02E3 for ; Fri, 21 Feb 2014 15:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPdIQxw8-qSZ for ; Fri, 21 Feb 2014 15:22:36 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B82291A0272 for ; Fri, 21 Feb 2014 15:22:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1362; q=dns/txt; s=iport; t=1393024953; x=1394234553; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jy9EjUIi8Z9qJRuWETQ9axPqvjwySny+VEr9dCI2okg=; b=app9ToU/oPx9hEPl/wdYSW4DCN4xIyO75ORIFSB+E4O9r7XcSHQ+JGuF z2lLAjWQEbZgO++dtlLBuNxcV6E6oIiib1Ce9Hbs6d+8jBCuuU0JBn/l7 Z/iH1YDj3hqwe2yAX45t5TBhnWmogEOWefmbQSh2AO0JZl/hbuNGAyN5A s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAPHeB1OtJV2c/2dsb2JhbABagwaBBgzAP4ENFnSCJQEBAQQ6NgkMBAIBCBEEAQELFBAyHQgCBA4Nh33LTReOAhEBHzEHBoMegRQBA6pbgy2BcTk X-IronPort-AV: E=Sophos;i="4.97,521,1389744000"; d="scan'208";a="305549566" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 21 Feb 2014 23:22:32 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1LNMW8w018432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Feb 2014 23:22:32 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 17:22:32 -0600 From: "Hemant Singh (shemant)" To: "Andrew Yourtchenko (ayourtch)" Subject: RE: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Topic: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Index: AQHPLg2r7NCj0C4O60mg5b5bMD7HkJq/uMUQgACJpgD//6YWsIAAqT8A///HhmA= Date: Fri, 21 Feb 2014 23:22:31 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89115F9FED@xmb-rcd-x06.cisco.com> References: <5305AF13.5060201@acm.org> <75B6FA9F576969419E42BECB86CB1B89115F99A9@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89115F9BAE@xmb-rcd-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/nRMMEscSkX33jDmRaGP6IDIBMsk Cc: Erik Nordmark , IETF IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 23:22:38 -0000 Andrew, -----Original Message----- From: Andrew Yourtchenko (ayourtch)=20 Sent: Friday, February 21, 2014 3:37 PM To: Hemant Singh (shemant) Cc: Erik Nordmark; IETF IPv6; Lorenzo Colitti Subject: RE: Comments on draft-yourtchenko-colitti-nd-reduce-multicast >Were they 802.11 clients ?=20 No. Sorry to not clarify that in my earlier email. I have tested 40K broa= dband modems (some modem were from a virtual modem generator) on a service = provider cable router in my lab.=20 >Wireless medium does have different properties. Agreed.=20 Did you make any "flash failure" events ? I thought a reload of a cable router and then getting modems online would b= e good to measure a failure though the failure may not be what you want and= once I understand flash failure, I can reply further, if need be. For s= ervice provider routers, I'd think a flash failure is the route processor c= ard crashed but being a service provider router, the router moves over to t= he standby route processer card and thus this box won't simulate a flash fa= ilure if I understand flash failure correctly. The switchover takes a few = seconds for a service provider router. =20 Wow, thanks for the detailed reply in rest of your email. Once I get a cha= nce to read that portion of your email, I will reply. Thanks much, Hemant From nobody Sat Feb 22 04:02:13 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60171A0072 for ; Sat, 22 Feb 2014 04:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGcBS9K6iEQZ for ; Sat, 22 Feb 2014 04:02:10 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 09AE01A0051 for ; Sat, 22 Feb 2014 04:02:10 -0800 (PST) Received: from dhcp-10-61-104-86.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 560F86059; Sat, 22 Feb 2014 04:02:02 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_D39290E3-BB61-4F88-BC68-08094797638D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast From: Ole Troan In-Reply-To: Date: Sat, 22 Feb 2014 13:02:00 +0100 Message-Id: <1607A96C-5760-42B0-ADFB-325F03D83834@employees.org> References: To: "Eric Levy- Abegnoli (elevyabe)" X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/9C3qfv0uoveCeKBX6k2My-u715Q Cc: Erik Nordmark , Andrew Yourtchenko , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 12:02:12 -0000 --Apple-Mail=_D39290E3-BB61-4F88-BC68-08094797638D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Eric, >> do we need to care about link-locals? are they part of the problem we >> need to solve? >=20 > Yes we do. They are about half the problem, an't they? More if most > traffic is local to the link. Less otherwise. I think that's an important point for the problem definition. I do agree with you that if we need to register link-local addresses = too, and change the model of link-local addresses always being on-link, = then we might look for other solutions. that's not what efficient ND = seems to do though. as far as I can see the ND efficient draft suggests = ND for link-local traffic is done like today. I did a couple of packet captures on my relatively fruity home network. = I did not see a single data packet using link-local addresses. I saw ND = and I saw lots of mDNS (someone needs to solve that problem too). I don't claim my home network is representative, but I'd really like to = see more data here. I presume we're not going to justify this work based on the 10000 node = dentist's office (1)? any application depending on link-locals would also break in the routed = home case. and if we really wanted to solve it, what's the solution space? - redefine link-locals to have an L-flag? - physically or virtually restricting the link-local subnet size? - disable link-locals? cheers, Ole (1) couldn't find a good reference to this use-case, anyone knows? I only got = http://ietfreport.isoc.org/idref/draft-ietf-dhcp-ipv4-autoconfig/ --Apple-Mail=_D39290E3-BB61-4F88-BC68-08094797638D 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 iQEcBAEBCgAGBQJTCJG4AAoJEFuJXizso86glCkH/3ana9FDeNuzcI4sNrFsr1co SL32OLxDDLb1jZbabyMuDvOJs9tnrmxd/uOuwPJxxxHiQRKeYsoGEsNY+5yDbDUK qHRJieUJMkQA1ChXi0yNpCKxd2rJLSN2YQk0xBd9h8Xa3j6DJPRFvoTI9b2kT9sh 78sZIsFtqUcrGyUq4t6e6wpChzZ1oG37XtjxTF/d+6IFcoBppHHCcfsbJSJX+rvh h3VpqR5Lm5EZBtdjWQsjLChigYkeDdWitEi2fsKsQpOYix0VG9jy+w/pnMb0UUMC rOmwuDMfsXLPlFhVDpiqcYJKd6CpRXLxQe1XnP0NN0igS+Ie+md7sm5UVleKkJE= =GPsz -----END PGP SIGNATURE----- --Apple-Mail=_D39290E3-BB61-4F88-BC68-08094797638D-- From nobody Sat Feb 22 16:08:13 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68001A0207 for ; Sat, 22 Feb 2014 16:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.913 X-Spam-Level: ** X-Spam-Status: No, score=2.913 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, J_CHICKENPOX_21=0.6, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPa8hJZYgQh0 for ; Sat, 22 Feb 2014 16:08:09 -0800 (PST) Received: from nm40-vm4.bullet.mail.bf1.yahoo.com (nm40-vm4.bullet.mail.bf1.yahoo.com [72.30.239.212]) by ietfa.amsl.com (Postfix) with ESMTP id 86B151A01AC for ; Sat, 22 Feb 2014 16:08:09 -0800 (PST) Received: from [98.139.215.140] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 23 Feb 2014 00:08:05 -0000 Received: from [98.139.212.211] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 23 Feb 2014 00:08:05 -0000 Received: from [127.0.0.1] by omp1020.mail.bf1.yahoo.com with NNFMP; 23 Feb 2014 00:08:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 79945.31543.bm@omp1020.mail.bf1.yahoo.com Received: (qmail 61915 invoked by uid 60001); 23 Feb 2014 00:08:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1393114084; bh=+O8hs/mEqGH0B2WuZQMmllxAdkL85IuKgyUB974VSXY=; 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=Lbm/aQ2SCJsBPSruB+ovAqkCHIxnYd0tydeweWrkrDqpRmyrp1N5h+mRaQJWClm4/Pdg1e2L76SwsqyZLIBfY795r6SHuCdwMSECBlOiJQNRj1WRAp5U/ext9eqYthaS++r6jROz4G4qnvLrPrriAikfdBpYbCIxH2TTLDrtZlw= 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=ooAbrDn12y+2+j2A9jN+8HCwp8J1idX+6fwIK2CN+GCOoyqJvlkT2ComODyORYBWHDYB+wd8hGOzarSA79DqweuWxbzoALxKCeYlgEpgAK9DpIv8xFhasKD/UTnvmUzwwasf7GGk5ibdeyV/z1lWvLOPLjzSdnwwXPD8aKjhSPM=; X-YMail-OSG: 5EGZfBEVM1lxU0ylTEED0c1fcNWWPv.3MgMVsuzyfbj4Dh6 4lP4Dc6CyTq729X3a7M4KXLEfnEy5xqcr_91Qy38RnNcN2sxTFVFLdBftSV7 NsGeFsO5DdaIJD97gCHZrzv5IqZ5UP8UTInoZHLM1m.SDfMv2axoKUGv4H7n y8_4oZ6U5LwrN4LXroO3ixvILbK.LvTQrbgjkmMsAmEORpqdwPQF_R8Up43C 2yc_VdEpm0_A2fFEIQGKpbk66gNLOFBhx7rIPSTNzHqx91GsGwshb6ND1N6K YriWTPr.O9VfucxHYW_NXKA6VeKXCzdmsRauQYwKE2I89T_ou.75TnkeVNux 5ZCkX6pTxIbEpmZaxcSKzlOmWJ.Q0ed2vwpJJiJSIZAeZd8HEIZ_niZ1zTd0 LnjaL4KTQd7ibHRfYCIGunSbV6TuQD0HuIUPxqBDjyQOhmqKaVAkDBaKPD7C RRkD9E3N1Ds00OjXyOttjP_gwBUCaYnPce2xgOfnozFcDgVo5jDhHAlrqYq2 mQPJtOYLdr.jQydd546pQThPTzbTfw.iAhxcGKv30W1FdwwunoQlCpmgOKzg uqelGIXjHaUFAOmaDJeBAibJvmw-- Received: from [150.101.221.237] by web162205.mail.bf1.yahoo.com via HTTP; Sat, 22 Feb 2014 16:08:04 PST X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBPbGUgVHJvYW4gPG90cm9hbkBlbXBsb3llZXMub3JnPgo.IFRvOiBFcmljIExldnktIEFiZWdub2xpIChlbGV2eWFiZSkgPGVsZXZ5YWJlQGNpc2NvLmNvbT4KPiBDYzogRXJpayBOb3JkbWFyayA8bm9yZG1hcmtAYWNtLm9yZz47IEFuZHJldyBZb3VydGNoZW5rbyA8YXlvdXJ0Y2hAY2lzY28uY29tPjsgNm1hbiBXRyA8aXB2NkBpZXRmLm9yZz4KPiBTZW50OiBTYXR1cmRheSwgMjIgRmVicnVhcnkgMjAxNCAxMTowMiBQTQo.IFN1YmplY3QBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <1607A96C-5760-42B0-ADFB-325F03D83834@employees.org> Message-ID: <1393114084.46822.YahooMailNeo@web162205.mail.bf1.yahoo.com> Date: Sat, 22 Feb 2014 16:08:04 -0800 (PST) From: Mark ZZZ Smith Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast To: Ole Troan , "Eric Levy- Abegnoli \(elevyabe\)" In-Reply-To: <1607A96C-5760-42B0-ADFB-325F03D83834@employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/x6FA1U3ragsdPSsmvJW0g6NsVGY Cc: Erik Nordmark , Andrew Yourtchenko , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 23 Feb 2014 00:08:12 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Ole Troan =0A> To: Eric Levy- Abegnoli (elevyabe) =0A> Cc= : Erik Nordmark ; Andrew Yourtchenko = ; 6man WG =0A> Sent: Saturday, 22 February 2014 11:02 PM=0A>= Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast=0A>= =0A> Eric,=0A> =0A>>> do we need to care about link-locals? are they part= of the problem we=0A>>> need to solve?=0A>> =0A>> Yes we do. They are ab= out half the problem, an't they? More if most=0A>> traffic is local to the= link. Less otherwise.=0A> =0A> I think that's an important point for the p= roblem definition.=0A> I do agree with you that if we need to register link= -local addresses too, and =0A> change the model of link-local addresses alw= ays being on-link, then we might =0A> look for other solutions. that's not = what efficient ND seems to do though. =0A> as far as I can see the ND effic= ient draft suggests ND for link-local traffic is =0A> done like today.=0A> = =0A> I did a couple of packet captures on my relatively fruity home network= . I did =0A> not see a single data packet using link-local addresses. I saw= ND and I saw lots =0A> of mDNS (someone needs to solve that problem too).= =0A> I don't claim my home network is representative, but I'd really like t= o =0A> see more data here.=0A> I presume we're not going to justify this wo= rk based on the 10000 node =0A> dentist's office (1)?=0A> =0A> any applicat= ion depending on link-locals would also break in the routed home =0A> case.= =0A> =0A> and if we really wanted to solve it, what's the solution space?= =0A> - redefine link-locals to have an L-flag?=0A> - physically or virtuall= y restricting the link-local subnet size?=0A> - disable link-locals?=0A>=A0= =0A=0ASo I've been thinking about this problem off-and-on for a few months = (specifically this, and more generally using hub-and-spoke link-layer forwa= rding in a multiaccess subnet, as I think it is a more general solution to = the various RA/DHCPv6 spoofing etc problems, and also is more energy effici= ent), and I've started writing up a draft which suggests the following solu= tion:=0A=0A- Allow RA PIOs to announce the link-local prefix, to switch the= on-link assumption for the link-local prefix off (the A bit in the PIO wou= ld be ignored for the LL prefix)=0A=0A- Routers perform a limited form of N= D proxying to facilitate hosts that don't support this LL RA PIO. ND proxyi= ng only occurs for Link-Local addresses.=0A=0AThe only issue I think that i= s left open after this link-local issue is host originated multicasts. The = link-layer forwarding model would force them to only be received by the rou= ter(s) at the hub(s). The question is how do the multicasts reach the other= hosts on the link?=0A=0ASimplistically, the router could just flood the mu= lticasts back to all hosts on the link (continuing to use the link-layer's = broadcast/multicast capability retained for the devices at the hub(s)). I d= on't know if that is legal, but assuming it is, would the multicast origin = host ignore its own multicasts? It could tell they were its own because the= source address would be one of its own. I've had a bit of a look into the = RFCs to see if this router and host multicast behaviour is defined, but hav= en't been able to find it.=A0=0A=0AAlternatively, the router could selectiv= ely forward the multicasts back to all hosts on the link except the one it = received it from. This could be achieved using link-layer unicasts and "MLD= v2 Procedures for Link-Layer Unicast Delivery of Multicast IPv6" (http://to= ols.ietf.org/html/draft-smith-mldv2-link-unicast-00).=0A=0ARegards,=0AMark. From nobody Sat Feb 22 16:29:42 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A5C1A0215 for ; Sat, 22 Feb 2014 16:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34c2ZNQjxuwg for ; Sat, 22 Feb 2014 16:29:38 -0800 (PST) Received: from nm47-vm8.bullet.mail.bf1.yahoo.com (nm47-vm8.bullet.mail.bf1.yahoo.com [216.109.115.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9523C1A021A for ; Sat, 22 Feb 2014 16:29:36 -0800 (PST) Received: from [98.139.215.140] by nm47.bullet.mail.bf1.yahoo.com with NNFMP; 23 Feb 2014 00:29:31 -0000 Received: from [98.139.212.229] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 23 Feb 2014 00:29:31 -0000 Received: from [127.0.0.1] by omp1038.mail.bf1.yahoo.com with NNFMP; 23 Feb 2014 00:29:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 789395.49745.bm@omp1038.mail.bf1.yahoo.com Received: (qmail 42894 invoked by uid 60001); 23 Feb 2014 00:29:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1393115371; bh=t7TdJBOfz6kv96WaDD1CwUhiHHp667fiYA6ZSS1cb+0=; 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=xeQlBiwFAB8M4MXc45A6mwmxNh08yM04B8ZK/kiltSL8P0EGYaUUoEc5LA83siBdnEvTWTDw0lM1gHbKybw0nLi3irV7CbGyMuE7bbrxMFmskgGUWro5V7jq4KeMxxO+CE4xWxLgQ04k995Ir6IF0o2ExTJeU/YKZPRZbINfyIo= 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=hhRgqvFstTCYWORnKOUwXAJ9qizEB+1AyPaEik41Zl+z+9JH9AQa7jKWBR7hE61eHTEsoLIcUsMbE3yk92WUe/w2MBD/twW/63kLun8aFt9unWmaatefR8p9W96MnQi0ZZg8TT9PhcMrXw+TgIE5l2QoBKii+7OHCas9lcJ3Wbs=; X-YMail-OSG: c6HkQ5UVM1mmmFz8smz9VCWv_t.V5wThUxTDLYyZ2ZR5JrI jtaWPr.3RBtmQ45._OZs6TY6wxA45K9DOFrwlqAShAjbBW9CJQMIUx4JpATB TT_hot13b0DKedgmNc51kSbBrvDOafY7hgo3d0doNme_sLqdBLYyblJwmGNZ qpzSHwg6qPkC.m2O4kMHtArRYqFguxhFnT8U_65DVgsnhpOCbJq9RbnpROOy uPkz8cocjVGbW7R2OK7lWYTt5BjlvY51HJqj5lG8lnV8J7HpnVo.ysM4FUhc wQMI72O4oa6ud3YSNE37NmCN10wSMhLjFBlwudV0lLbyqzbJVqpfMK2qokOW 0cBeiL4Gj947gRopkK_QuCWrtcFOUJ0HslCBjEQ4cLKomtBUXCW3FxPip71I UPQztgiFpnkENjKD0jOL4y.qBRg4GXtleQQf2jJz6r0BLV_Ae0ZI8rHMnp8z efDMIvXDXnnHtKoykdZtykHxg7wWHzhJZeHb0lMg2mDCmHMZnamHQdgmTg.P NGlkcGpmfO1nx4dElR3NpzhwVA25eLxVcWsJ1bqQE.sR.vTnnMGObwWsZA7z SGcFBcFT8t7InGFQ7yHQL Received: from [150.101.221.237] by web162206.mail.bf1.yahoo.com via HTTP; Sat, 22 Feb 2014 16:29:31 PST X-Rocket-MIMEInfo: 002.001, SGkgRmVybmFuZG8sCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206IEZlcm5hbmRvIEdvbnQgPGZnb250QHNpNm5ldHdvcmtzLmNvbT4KPiBUbzogTWFyayBaWlogU21pdGggPG1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU.OyAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPjsgImktZC1hbm5vdW5jZUBpZXRmLm9yZyIgPGktZC1hbm5vdW5jZUBpZXRmLm9yZz4KPiBDYzogImlwdjZAaWV0Zi5vcmciIDxpcHY2QGlldGYub3JnPgo.IFNlbnQ6IFcBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <20140214184335.29433.45425.idtracker@ietfa.amsl.com> <1392435444.66015.YahooMailNeo@web162206.mail.bf1.yahoo.com> <53039F2E.2060209@si6networks.com> Message-ID: <1393115371.66471.YahooMailNeo@web162206.mail.bf1.yahoo.com> Date: Sat, 22 Feb 2014 16:29:31 -0800 (PST) From: Mark ZZZ Smith Subject: Re: I-D Action: draft-ietf-6man-ipv6-address-generation-privacy-01.txt To: Fernando Gont , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" In-Reply-To: <53039F2E.2060209@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/s5nZgI-pzEtkdkVFb5IxIg9xQCc Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 23 Feb 2014 00:29:40 -0000 Hi Fernando,=0A=0A=0A----- Original Message -----=0A> From: Fernando Gont <= fgont@si6networks.com>=0A> To: Mark ZZZ Smith ; = "internet-drafts@ietf.org" ; "i-d-announce@ietf.o= rg" =0A> Cc: "ipv6@ietf.org" =0A> Sen= t: Wednesday, 19 February 2014 4:58 AM=0A> Subject: Re: I-D Action: draft-i= etf-6man-ipv6-address-generation-privacy-01.txt=0A> =0A> On 02/15/2014 12:3= 7 AM, Mark ZZZ Smith wrote:=0A> =0A>> =0A>> I think it would be useful to = not specifically couple address=0A>> configuration methods (SLAAC, DHCPv6,= static/manual) with address=0A>> generation methods (MAC derived, RFC4941= , cryptographically generated=0A>> etc.). I think what is being discussed = about addresses equally=0A>> applies regardless of the address configurati= on method used to=0A>> configure the resulting IPv6 address on an interfac= e.=0A> =0A> Makes sense -- although for the most part, they do seem to be c= oupled in=0A> practice.=0A>=A0=0A=0AI think that has been a coupling of "co= nvenience" more than a necessity. I think it is also the origin of the issu= es where when DHCPv6 or SLAAC is switched off on a link, the DHCPv6 or SLAA= C configured addresses have been removed from the hosts' interfaces, even t= hough the addresses still had valid lifetimes. I've come to the belief that= the only address expiry mechanism is their lifetimes, and the lifetimes, w= hile set by the address configuration method used, are the only determinant= of whether the address should be expired or not.=0A=0A=0A=0A> =0A> e.g., h= ow do you do CGAs with DHCPv6, etc.?=0A> =0A> It seems to me that while the= re's a distinction between the mechanism=0A> used for address configuration= and the resulting IID, for most cases=0A> there's a 1 to 1 mapping... and = it's valuable how such IIDs are=0A> typically generated.=0A>=A0=0A=0AI'm no= t sure there is a 1:1 mapping very often, though it might be implied by the= various RFCs that have coupled them together. However, if you go through a= variety of examples of IID generation methods, and think of the methods th= at can or could be used to configure them, most of the time they aren't ver= y exclusive.=0A=0AFor example, privacy addresses can be configured via SLAA= C or via DHCPv6 (IA_TA option). The could also be configured manually, by g= enerating the address and then setting non-infinite lifetimes. So the priva= cy address generation mechanism isn't coupled to a single address configura= tion method.=0A=0AAs another example, consider EUI-64 derived. Used by SLAA= C, however I don't think there is any technical reason why a DHCPv6 server = couldn't generate addresses based on the EUI-64 form of the link-layer sour= ce address the host used, and then dole them out to the hosts. They could b= e configured manually too.=0A=0AI thought the same for your Opaque IDs addr= ess generation method, which is why I suggested the text to say that this m= ethod isn't exclusively tied to SLAAC. DHCPv6 servers could use the opaque = IID address generation method, and it could also be used to generate addres= ses that are then manually configured on the host (perhaps via a boot scrip= t).=0A=0AI agree there are some cases where the address generation and addr= ess configuration methods are tightly coupled, such as your CGA with DHCPv6= example. However I think they're the exception rather than the rule, which= is why I think there is value in treating address generation as a distinct= function that is usually separate from address configuration. (In summary,= I think there are 3 distinct addressing related functions - address genera= tion (privacy, opaque, EUI-64), address configuration (SLAAC, DHCPv6, stati= c/manual) and address expiry (valid lifetime)).=A0=0A=0A=0ARegards,=0AMark.= =0A=0A=0A> Thoughts?=0A> =0A> Thanks,=0A> -- =0A> Fernando Gont=0A> SI6 Net= works=0A> e-mail: fgont@si6networks.com=0A> PGP Fingerprint: 6666 31C6 D484= 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492=0A> From nobody Sun Feb 23 19:35:57 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06C21A028E for ; Sun, 23 Feb 2014 19:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28iJ-tJS4559 for ; Sun, 23 Feb 2014 19:35:54 -0800 (PST) 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 621211A027D for <6man@ietf.org>; Sun, 23 Feb 2014 19:35:54 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id kq14so5947642pab.17 for <6man@ietf.org>; Sun, 23 Feb 2014 19:35:54 -0800 (PST) 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=I4gUfXyCGXKo178rRgUq5AzRu6MCutE4c2R4h5pX3Po=; b=G49YOOQVw9V7XrDlrZlFEffxOoeLvdxtbOic+kd/wMm9ZMZqoM1T3nMYXP+hD75c2f 9JywVuJqElOBnuQkd+o19oNkNFTKxFhku4iroto8mPrVfOKbchyCBTbUSrKT5W4UF9At 1d5ucMeqPpd0OvfdZKjTE7lCwJnQo8Dn0qiioUl1TA8X3+B/jLKvDm4YenpebGDvPUO8 E7tZCE1sZX0kPSDt2c0Aa7FUqowUGTzvbiQ/IvM8Fw4wxIw8tDtFuxw4N/BLkZoXgDjH 8Q8FLGF9eXYSbF1YJxOCDlaR8NL6vv4RUOf2uH/njhG8xI31axSqBWP1OnNOP7rVqYie TwAA== X-Received: by 10.66.149.7 with SMTP id tw7mr22512463pab.72.1393212954143; Sun, 23 Feb 2014 19:35:54 -0800 (PST) Received: from [192.168.178.23] (155.199.69.111.dynamic.snap.net.nz. [111.69.199.155]) by mx.google.com with ESMTPSA id ou9sm146027pbc.30.2014.02.23.19.35.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 23 Feb 2014 19:35:53 -0800 (PST) Message-ID: <530ABE15.8090307@gmail.com> Date: Mon, 24 Feb 2014 16:35:49 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "6man@ietf.org" <6man@ietf.org> Subject: Re: New Version Notification for draft-sarikaya-6man-next-hop-ra-00.txt References: <20140210213947.14657.20184.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/aV2mgld8ob2pF6uz12E9FqTPzOY Cc: =?UTF-8?B?RGFuIEzDvGR0a2U=?= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 03:35:56 -0000 On 15/02/2014 06:35, Dan L=C3=BCdtke wrote: > Hi, >=20 > I have very mixed feelings regarding this draft and I have not yet > decided whether it is me or the draft :) It's probably the fact that the community is very divided as to whether this, or a DHCPv6 based solution, is the right one for delivering routing information to hosts. Personally I see advantages in defining enough in RA that a DHCPv6-free network is possible, but it only makes sense if we insist that routing information capable of delivery by RA and that capable of delivery by DHCPv6 have *exactly* the same semantics (even if the syntax of the messages is different). =2E.. > I also have the feeling that consuming 7 numbers from the registry for > new options is a bit too greedy. Do you see any way to reduce the > consumption of this very limited resource? I think it would help > supporting the draft a lot. Since an address is the same thing as a /128 prefix, I would think that the address TLVs could be replaced by prefixes, which would save at least a couple of option numbers. If that isn't enough, it would have to go to subtypes. Brian From nobody Sun Feb 23 20:05:25 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523861A07F1 for ; Sun, 23 Feb 2014 20:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSwKlZVoFsIW for ; Sun, 23 Feb 2014 20:05:22 -0800 (PST) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCA51A07F0 for <6man@ietf.org>; Sun, 23 Feb 2014 20:05:22 -0800 (PST) Received: by mail-pb0-f52.google.com with SMTP id rp16so1433080pbb.11 for <6man@ietf.org>; Sun, 23 Feb 2014 20:05:22 -0800 (PST) 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=wgXtcr4hWUk/kwO4cuH3XtEmHmxBgTSTWfgXBn3V3I8=; b=04OTYV4vcl9/FofDxMfOXsdUSDZkCXF3mBmnSKosro1vWiSX+VSLvOP+1J22snexTt vfxfs8go/Dve0b28Q9FMbZ5udU+q5/lQ8ZfmT/kAkMem7S+Vo9pweBz5rGGDGE8XuEsC E+euhratS1x7WIdpPZMK9JVFMcLhM8hYsoGtojma2vvDD6eeBUSRVQZLy+Y6ODgc87O0 2Kh8BPvNxgMKPD+sJBKxKeSr+QJVvsQcqnM8SaggdFBQ8ZYOWRrKFTB6h8/oibLowwlM A2RZ9ES9rQwsQZpliL8TBWibNw5yut/9zxrGifBYJ/SNc1+YWZjlC/rZWzyi/O8LrAdI PBKw== X-Received: by 10.68.139.100 with SMTP id qx4mr22364235pbb.144.1393214722028; Sun, 23 Feb 2014 20:05:22 -0800 (PST) Received: from [192.168.178.23] (155.199.69.111.dynamic.snap.net.nz. [111.69.199.155]) by mx.google.com with ESMTPSA id lb4sm23626524pbc.11.2014.02.23.20.05.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 23 Feb 2014 20:05:21 -0800 (PST) Message-ID: <530AC4FC.6020702@gmail.com> Date: Mon, 24 Feb 2014 17:05:16 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "C. M. Heard" Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <52F13D1D.9050800@gont.com.ar> <52F804B3.5040803@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/iDZthptGGbrh8Zvc4UWZhj5GYpY Cc: 6MAN <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 04:05:24 -0000 Mike, You ended this message with > Thoughts? I think your analysis is pretty much spot on. Maybe the best we can do is: a) State that new requirements SHOULD be defined as payloads. b) If not, they MUST be defined as options unless there is an unavoidable technical reason that they can't be. That doesn't seem to be significantly different from saying that they MUST be sub-options of a new generic header. In any case, firewalls will want to parse these options. BTW, RFC6564 already says this at SHOULD level. c) Re-iterate that RFC6564 requires a uniform format. d) Re-iterate that RFC7045 requires middleboxes to handle all defined extension headers. Note that a) above is the only really new thing here. But if d) is implemented, middleboxes can find the payload, and if a) and b) are implemented, there will not be any new extensions except in extreme circumstances. BTW, the subject of this thread has been wrong from the start: s/6465/6564/. I didn't correct it because of threaded mail readers. Regards Brian On 12/02/2014 19:42, C. M. Heard wrote: > On Mon, 10 Feb 2014, Brian E Carpenter wrote: >> On 10/02/2014 08:35, C. M. Heard wrote: >> ... >>> In the absence of a strong argument to the contrary, it seems to me >>> that the existing Destination Options header can be used to do >>> exactly the same thing as the proposed UEH. In other words, I agree >>> with Jen's comments. >> I think we should carry out a thought experiment: consider each >> of the existing extension headers, listed in RFC 7045 and at >> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header >> and see which of them could or could not be encoded as >> destination options. >> >> For some of them the answer is obvious, of course. But the others would >> give us an idea whether the 'option' option has enough flexibility. > > That is a good idea and I am going to take a stab at it. In looking > over the references for the existing extension headers listed in RFC > 7045 and in the above-referenced IANA registry it appears to me that > the order in which headers other than experimental use headers 253 > and 254 should appear is as follows (this is an update of RFC 2460 > Section 4.1): > > IPv6 header > Hop-by-Hop Options header > Destination Options header (note 1) > Routing header > Shim6 header > Fragment header > Authentication header (note 2) > Encapsulating Security Payload header (note 2) > Destination Options header (note 3) > Mobility Header or Host Identity header (note 4) > upper-layer header > > 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. > > note 2: additional recommendations regarding the relative > order of the Authentication and Encapsulating Security > Payload headers are given in [RFC-2406]. > > note 3: for options to be processed only by the final > destination of the packet. > > note 4: at present, these headers are required to contain > No Next Header, so an upper-layer header will not follow > these headers. > > To see if the 'option' option has enough flexibility, let's consider > each header in turn to see whether it could reasonably be replaced > by one of the following: > > - hop-by-hop option > - destination option > - upper-layer header > > or (for the three kinds of headers listed above) how the rules for > usage would be changed by a ban on new IPv6 extension headers. > > This is a bit more general question than the one posed by Brian > Carpenter, but I think it's the right way to go when determining > whether a ban on new extension headers would limit flexibility. > > Hop-by-Hop Options header: this header is needed to clearly > distinguish hop-by-hop and destination options. It is (and always > has been) the only means to include optional IPv6 data with > hop-by-hop semantics. A ban on new extension headers would not > change this. > > Destination Options header: this header is needed to clearly > distinguish hop-by-hop and destination options. Using a destination > option in place of an extension header could require that this > header be allowed to appear more than twice in the IPv6 header chain > or introduce constraints regarding the order in which destination > options would be allowed to appear. > > Routing header: IPv4 provides an existence proof that this extension > header could be replaced by a destination option. Such an option > would be carried in a Destination Options header immediately > following the Hop-by-Hop Options header if present or the IPv6 > header otherwise. > > Shim6 header: as far as I can tell, the situation is exactly the > same as for the Routing header. In cases where an IPv6 packet > contains only Shim6 control information and no ULP data, the Next > Header value of the containing Destination Options header would be > No Next Header. > > Fragment header: it is my assessment that while it might be possible > to make this into a destination option, that would add a good deal > of awkwardness to an already awkward and error-prone function. On > that basis I would say that using an extension header was justified > in this case. > > Authentication header: it certainly would be possible to encode the > equivalent information into a destination option, but because of the > fact that the authentication is done prior to fragmentation or after > reassembly it would be necessary to allow a separate Destination > Option header to appear where the Authentication header now appears. > However, since AH is used for both IPv4 and IPv6, that would not > have been a good engineering choice, and I would say that using an > extension header was justified in this case. > > Encapsulating Security Payload header: as noted in RFC 4303, "in the > IPv6 context, ESP is viewed as an end-to-end payload," and we treat > is as such when determining where an IPv6 header chain ends. It > would not make sense to replace it with a destination option, > but if the concept of an extension header did not exist, we would > just treat it as an upper-layer header that contains tunneled > encrypted data. > > Mobility Header and Host Identity header: unless I am missing > something, these are used to carry control messages and always > have a Next Header value of No Next Header, allowing some > future flexibility to include piggybacked data in a standard > way. As far as I am able to tell, exactly the same goal could > be achieved by defining these as upper-layer protocol headers. > > Experimental Use headers (protocol numbers 253 and 254): since > these could be either extension headers or transport protocols > per then whim of the experimenter, there is no defined function > to evaluate. However, if we go with the 'option' option, these > would turn into experimental upper-layer headers, and the > experimental-use options would be used for experiments that > wanted to "sandwich" optional data into an IPv6 header. > > Thoughts? > > Mike Heard > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > . > From nobody Mon Feb 24 01:57:42 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF271A0849 for ; Mon, 24 Feb 2014 01:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gi73fipTBnc9 for ; Mon, 24 Feb 2014 01:57:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A9A761A0848 for ; Mon, 24 Feb 2014 01:57:37 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBL29623; Mon, 24 Feb 2014 09:57:35 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 24 Feb 2014 09:57:22 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 24 Feb 2014 09:57:24 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.224]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Mon, 24 Feb 2014 17:57:20 +0800 From: "Liubing (Leo)" To: IPv6 IPv6 List Subject: Clearing the ambiguity in DHCPv6/SLAAC interaction-//FW: New Version Notification for draft-liu-6man-dhcpv6-slaac-implementation-guide-00.txt Thread-Topic: Clearing the ambiguity in DHCPv6/SLAAC interaction-//FW: New Version Notification for draft-liu-6man-dhcpv6-slaac-implementation-guide-00.txt Thread-Index: AQHPKWzOhXnu5rFIOU+zjAYPxfhpwJrEKvzQ Date: Mon, 24 Feb 2014 09:57:20 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8535C2@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/AzpVOzM87rLQ-e4_sqxvSVtNR8s X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 09:57:40 -0000 SGkgRGVhciBhbGwsDQoNCldlJ3ZlIGRpc2N1c3NlZCB0aGUgREhDUHY2L1NMQUFDIGFkZHJlc3Mt Y29uZmlnIHByb2JsZW1zIGluIDZtYW4gYSBjb3VwbGUgb2YgdGltZXMgYmVmb3JlLiANCkluIHN1 bW1hcnksIHRoZSBwcm9ibGVtIGlzIHJlZ2FyZGluZyB3aXRoIHRoZSBhbWJpZ3VpdHkgb24gaW50 ZXJwcmV0aW5nIHRoZSBNIGZsYWcgYW5kIE8gZmxhZyBpbiBORCBtZXNzYWdlcy4gRGlmZmVyZW50 IG9wZXJhdGluZyBzeXN0ZW1zJyBiZWhhdmlvciBoYXMgdmFyaWVkIG9uIGludGVycHJldGluZyB0 aGUgZmxhZ3MsIGVzcGVjaWFsbHkgd2hlbiBmbGFncyBhcmUgaW4gdHJhbnNpdGlvbi4NCg0KSW4g bGFzdCBpZXRmLCB0aGUgZHJhZnQgZGlzY3Vzc2luZyB0aGUgaXNzdWVzIHdhcyBhZG9wdGVkIGJ5 IHY2b3BzIHRvIGJlIGEgcHJvYmxlbSBzdGF0ZW1lbnQgZG9jdW1lbnQgKGRyYWZ0LWlldGYtdjZv cHMtZGhjcHY2LXNsYWFjLXByb2JsZW0pLg0KUGVvcGxlIGZyb20gT1BTIGFyZWEgYWdyZWVkIHRo YXQgdGhlIHByb2JsZW1zIG5lZWQgdG8gYmUgc29sdmVkLCBhbmQgc3VnZ2VzdGVkIHVzIHRvIGlu aXRpYWwgYW5vdGhlciB3b3JrIGluIDZtYW4gdG8gZGlzY3VzcyBob3cgdG8gZGVhbCB3aXRoIHRo ZSBpc3N1ZXMuIA0KDQpTbyBiZWxvdyBpcyBqdXN0IHRoZSBkcmFmdCwgaXQgaXMgdG8gc3BlY2lm eSB0aGUgcHJvcGVyIGJlaGF2aW9yIHdoZW4gdGhlIGhvc3RzIGludGVycHJldGluZyB0aGUgcmVs ZXZhbnQgZmxhZ3MgKEEgZmxhZywgTSBmbGFnIGFuZCBPIGZsYWcpIGluIGRpZmZlcmVudCBzdGF0 ZXMuDQoNClBsZWFzZSBoYXZlIGEgcmV2aWV3LCBhbmQgY29tbWVudCB3aGV0aGVyIHlvdSBhZ3Jl ZSB0aGUgYXBwcm9hY2hlcy4NCkFuZCB3ZSdyZSBvcGVuIHRvIGRpc2N1c3Npbmcgb3RoZXIgcHJv cG9zYWxzIHRvIGNsZWFyIHRoZSBhbWJpZ3VpdHkgKGUuZy4gcmV2aXNpbmcgdGhlIHJlbGV2YW50 IHNwZWNpZmljYXRpb24gaW4gUkZDNDg2MS80ODYyKSwgc28gcGxlYXNlIGZlZWwgZnJlZSB0byBj b21tZW50Lg0KDQpNYW55IHRoYW5rcyENCg0KQmVzdCByZWdhcmRzLA0KQmluZw0KDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAx NCwgMjAxNCA2OjA5IFBNDQpUbzogTGl1YmluZyAoTGVvKTsgUm9uIEJvbmljYTsgTGl1YmluZyAo TGVvKTsgUm9uIEJvbmljYQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1saXUtNm1hbi1kaGNwdjYtc2xhYWMtaW1wbGVtZW50YXRpb24tZ3VpZGUtMDAudHh0DQoN Cg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxpdS02bWFuLWRoY3B2Ni1zbGFhYy1pbXBs ZW1lbnRhdGlvbi1ndWlkZS0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgQmluZyBMaXUgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJ ZHJhZnQtbGl1LTZtYW4tZGhjcHY2LXNsYWFjLWltcGxlbWVudGF0aW9uLWd1aWRlDQpSZXZpc2lv bjoJMDANClRpdGxlOgkJREhDUHY2L1NMQUFDIEludGVyYWN0aW9uIEltcGxlbWVudGF0aW9uIEd1 aWRhbmNlDQpEb2N1bWVudCBkYXRlOgkyMDE0LTAyLTE0DQpHcm91cDoJCUluZGl2aWR1YWwgU3Vi bWlzc2lvbg0KUGFnZXM6CQk2DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtbGl1LTZtYW4tZGhjcHY2LXNsYWFjLWltcGxlbWVudGF0aW9u LWd1aWRlLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWxpdS02bWFuLWRoY3B2Ni1zbGFhYy1pbXBsZW1lbnRhdGlvbi1ndWlkZS8N Ckh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saXUtNm1h bi1kaGNwdjYtc2xhYWMtaW1wbGVtZW50YXRpb24tZ3VpZGUtMDANCg0KDQpBYnN0cmFjdDoNCiAg IE5EIGFuZCBESENQdjYgcHJvdG9jb2xzIGNvdWxkIGhhdmUgc29tZSBpbnRlcmFjdGlvbiBvbiBh ZGRyZXNzDQogICBwcm92aXNpb25pbmcgd2l0aCB0aGUgQSwgTSwgYW5kIE8gZmxhZ3MgZGVmaW5l ZCBpbiBORCBwcm90b2NvbC4gQnV0DQogICB0aGUgcmVsZXZhbnQgc3RhbmRhcmQgZGVmaW5pdGlv bnMgb2YgdGhlIGZsYWdzIGNvbnRhaW4gYW1iaWd1aXR5LCBzbw0KICAgdGhhdCBjdXJyZW50IGlt cGxlbWVudGF0aW9ucyBpbiBvcGVyYXRpbmcgc3lzdGVtcyBoYXZlIHZhcmllZCBvbg0KICAgaW50 ZXJwcmV0aW5nIHRoZSBmbGFncy4gVGhlIHZhcmlhdGlvbiBtaWdodCBpbXBhY3QgcmVhbCBuZXR3 b3JrDQogICBvcGVyYXRpb25zLCBzbyB0aGlzIGRvY3VtZW50IGFpbXMgdG8gcHJvdmlkZSBzb21l IGd1aWRhbmNlIG9uIHdoYXQNCiAgIHNob3VsZCBiZSB0aGUgcHJvcGVyIGltcGxlbWVudGF0aW9u IG9uIHRoZSBpbnRlcmFjdGlvbiBiZWhhdmlvci4NCg0KDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNl Y3JldGFyaWF0DQoNCg== From nobody Mon Feb 24 02:04:57 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2AC31A043E for ; Mon, 24 Feb 2014 02:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NljKZbRlXsb6 for ; Mon, 24 Feb 2014 02:04:51 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 845521A0428 for ; Mon, 24 Feb 2014 02:04:51 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id b8so5380830lan.19 for ; Mon, 24 Feb 2014 02:04:50 -0800 (PST) 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=XVUnlb/WvatHaTCctx9Y0ZpPPxONCVf3KmxsST1RQxY=; b=XDmR/R8jFLCu6nF8FFRczl6zf/m7bUztjM2xlysvKSde49OA+2KxC5J2+Wq5rLpFzD jDE3LesWY/9fvVo04y9sRI1kazRwD5cv2H/dIqB+kxFXxvQlNfTzkK3cUuhHBCDAfKHe 3+aJ9ofHvX6Vl1n8DsF2n+kgrx1HRRsw3UiqLr3AMhWx1ZKAn/+F1ChtpmncCp56VHD0 e/zZmufLWCHpUHhqfKi32qgBebGCAjPUQLj9asl9XqlAgyN17phm8zXnyIUksAQuX5oq 2XIgoifyWDfUdry+IZG1sJOpx6mF/UKS1LGRmwPwfSh60nPReRG0lYrXgSMVu2bWW1PH ab/w== X-Received: by 10.152.203.193 with SMTP id ks1mr11779736lac.0.1393236290140; Mon, 24 Feb 2014 02:04:50 -0800 (PST) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id gb8sm18065387lbc.13.2014.02.24.02.04.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Feb 2014 02:04:49 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: comments on draft-ietf-6man-enhanced-dad-04 From: Jouni Korhonen In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89115F5DD1@xmb-rcd-x06.cisco.com> Date: Mon, 24 Feb 2014 12:04:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <796E1FAC-8B6F-42F4-9D6B-27D37B86F805@gmail.com> References: <78AE6729-1A26-48EA-BD31-FBBDE85C829E@gmail.com> <75B6FA9F576969419E42BECB86CB1B89115F5DD1@xmb-rcd-x06.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/GTU0xV1wdXMFCDGwTW6KfF4bssw Cc: "draft-ietf-6man-enhanced-dad@tools.ietf.org" , IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 10:04:53 -0000 Hi Hemant, Sorry for a slow reply.. been reading other lists lately ;-) Comments = inline. On Feb 19, 2014, at 3:11 AM, Hemant Singh (shemant) = wrote: > Jouni, >=20 > Good to hear from you - thanks much for the review. Humble apologies = for the delay - both WesB and I were busy. We discussed your comments. = Please see in line below between and . >=20 > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Monday, February 10, 2014 11:05 AM > To: draft-ietf-6man-enhanced-dad@tools.ietf.org; IPv6 IPv6 List > Subject: comments on draft-ietf-6man-enhanced-dad-04 >=20 > Authors, >=20 > I have a read on this document. I find it good and informative. Few = comments and questions inline. >=20 > ** Abstract >=20 > o There is no mention that this document updates RFC4861 and RFC4862. >=20 > The reason is because the top-left of the document says "Update: = 4862, 4861". Would you like the Abstract to also mention the same = fact? WE will also add that this document also updates the SEND RFC. > It is just the IDnits complains if the abstract does not state that "updates RFC xyz etc". That's why I prefer those being there. Listing update to SeND RFC is good as well! >=20 > ** Section 1 >=20 > specified in [RFC4862]. Failure also includes if the Target > Address is optimistic. Optimistic DAD is specified in [RFC4429]. >=20 > o I do not understand the sentence "Failure also includes if the = Target > Address is optimistic." Some word missing there? >=20 > I meant to say, the failure covers both a tentative and an = optimistic address where the tentative address is defined in RFC 4862 = and the optimistic address is defined in RFC 4429. Either address type = can be the TargetAddress of the DAD probe . Either address type can = also fail DAD due to a looped back DAD and both protocols use the same = failure mechanism defined in RFC 4861.=20 >=20 > New text: >=20 > [Duplication Address Detection failure as specified in [RFC4862]. = Note even Optimistic DAD as specified in [RFC4429] can fail due to a = looped back DAD probe. This document covers looped back detection for = Optimistic DAD as well. ] >=20 > Looks good to me now. >=20 > ** Section 3.2 >=20 > This solution requires no protocol changes. This solution SHOULD be > enabled by default, and MUST be a configurable option. >=20 > o I would clarify here, just to be clear on the context, that the = above > MUST applies only if the layer 2 has an ability to detect looped back > messages. Proposed text: >=20 > This solution requires no protocol changes. This solution SHOULD be > enabled by default, and MUST be a configurable option if the layer 2 > technology provides means for detecting loopback messages on an > interface circuit. >=20 > Perfect suggestion and thanks for the text. We will take the = text. Ack. >=20 > ** Section 4 >=20 > SEND. See more details in the Impact on SEND section. Since a = nonce > ^^^^^^^^^^^^^^^^^^^^^^^ >=20 > o I would point explicitly to the section number as well. > ok. Thanks. >=20 > o The algorithm description in the second paragraph is somewhat hard = to > follow. I had to read it quite many times.. On the other hand, the > algorithm description in Section 4.2 is far more readable. Consider > having the algorithm description only in one place. >=20 > Agreed. Most of the second paragraph will be deleted and we will = reference section 4.2 in the second paragraph. Good. Thanks. >=20 > ** Section 4.2 >=20 > The MAX_MULTICAST_SOLICIT number of > NS(DAD) messages sequence continues until the stop condition is > reached. >=20 > o Or manual administrative actions are taken, right? >=20 > Yes. New text below: >=20 > The MAX_MULTICAST_SOLICIT number of NS(DAD) messages sequence = continues until the stop condition is > Reached or manual intervention is undertaken. >=20 > Ack. >=20 >=20 > o The stop condition and ending the probing means the interface moves > the Target Address to assigned state, right? I would say that > explicitly. >=20 > OK - will do. Note one reviewer (in private email) wanted the = address to move to assigned state whether a looped back DAD was received = within the RetransTimer milliseconds interval or not. But I replied, = what good is an assigned address until I the interface detects the = loopback has stopped because unless the loopback stops, the assigned = address can be used to only to send traffic that is looped right back. =20= > Ok. Thanks. >=20 > ** Section 4.4 >=20 > detecting looped back ND messages. If this document updates > [RFC4862], SEND should be updated to integrate with the Enhanced DAD > algorithm. A minor update to SEND would be to explicitly mention >=20 > o "If this document updates.." well it does. Propose changing the text = to > something like "Since this document.." > o Why there is no proposal for those "minor" SEND updates? >=20 > Will take your suggestion and propose text in our next revision. = Ok. Thanks. >=20 > ** Section 4.5 >=20 > The following text is added to [RFC4862]. >=20 > o Added where in RFC4862? Propose an explicit place. > o The added text should probably have a reference to this document. >=20 > Ok, will do. Ack. >=20 > ** Section 4.6 >=20 > o Changes where exactly in RFC4861? Propose an explicit place. > o The added text should probably have a reference to this document. >=20 > Ok, will do. Ack. >=20 > ** Section 6 >=20 > algorithm. SEND is recommended for this exploit. For any = mitigation >=20 > o I would say SEND is not recommend for this exploit rather SEND is = recommended > to circumvent this exploit. >=20 > Agreed. Will take your suggestion. Ack. >=20 > ** Section 9 >=20 > o Obsolete normative reference to RFC1247 (obsoleted by RFC1583) o No = reference to RFC2119 (also there is no typical RFC2119 boilerplate text) = o draft-ietf-6man-impatient-nud -> RFC7048 >=20 > will do Ack. >=20 > Thanks much, You are welcome! - Jouni >=20 > Hemant >=20 From nobody Mon Feb 24 02:06:32 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A861A0859 for ; Mon, 24 Feb 2014 02:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWkUWaoufB1B for ; Mon, 24 Feb 2014 02:06:29 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id BB6181A085A for ; Mon, 24 Feb 2014 02:06:28 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id mc6so1909778lab.13 for ; Mon, 24 Feb 2014 02:06:27 -0800 (PST) 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=XHlUalPF3sDzXUgeljK9Es5wBP+aE8EncotbLLmXpn8=; b=oizNXxvdevkxu48JVDHtyL7P+oppdnblUM+5UuPylQu+z0Tirv8xzKZssALxUst/1q iuT35aV7TbD4UhxrjGpGxLqWr9Bk6SE4xixpstICAgiot8PMBbqbF7lwidZaIEWLzHyQ nxq91rcK803MrDPyLQC1sMsrNpoZhtA4GW0/TGqZuaCtCjHIpc10no4qDrPFWA93Q4zF nyuh8aWjiCpLDABEcuCtQoz+wsAhPu9chsAz0m0XspIf+NDjCcgRLwvHNG/QAnW01dv5 2qZ6HTdjLzTGE+1+bvi38WwGYokPprUhuvGfWJBt4XSAk6lpahGjMCWKKfuDr8QauGqO p9FQ== X-Received: by 10.152.228.172 with SMTP id sj12mr11726302lac.32.1393236387575; Mon, 24 Feb 2014 02:06:27 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:995d:2aa6:edf0:6bc6? ([2001:1bc8:101:f101:995d:2aa6:edf0:6bc6]) by mx.google.com with ESMTPSA id v5sm24944416laj.0.2014.02.24.02.06.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Feb 2014 02:06:27 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Comments on draft-ietf-6man-multicast-scopes-02 From: Jouni Korhonen In-Reply-To: <30F57851-87B7-4260-B1C0-A56681020C9B@cisco.com> Date: Mon, 24 Feb 2014 12:06:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6F6D0664-A4A8-4113-B036-FAA2E742FBF2@gmail.com> References: <30F57851-87B7-4260-B1C0-A56681020C9B@cisco.com> To: Ralph Droms (rdroms) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/JYZgIS-0XxtX-bnaTTRwLDKCLbY Cc: "draft-ietf-6man-multicast-scopes@tools.ietf.org" , IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 10:06:30 -0000 Looks good to me now. - Jouni On Feb 14, 2014, at 2:52 AM, Ralph Droms (rdroms) = wrote: > draft-ietf-6man-multicast-scopes-03.txt addresses the comment posted = during the WG last call (see attached diff). >=20 > In my opinion, this rev of the document is ready to be sent to the = IESG. >=20 > - Ralph >=20 > = --------------------= ------------------------------------------------ > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Mon Feb 24 12:52:25 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D364C1A0262 for ; Mon, 24 Feb 2014 12:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2C4DXWsyCsZ for ; Mon, 24 Feb 2014 12:52:17 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 91D301A0234 for ; Mon, 24 Feb 2014 12:52:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=839; q=dns/txt; s=iport; t=1393275137; x=1394484737; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2rNH27smAMX9UZgdvmLl9QkfMDxfIgOx3V3nF2bnEJI=; b=Acg/l2jHkgtgpEIHy8bl9xZR21mSkWhY+wUro7gDyEik8S2OK96e0PIX Ci2p24hH66FuOY7RbqyH7SGl+5W03bROr1WdJpaBrKnb64tqfHu8w/F2n Te4fJe2pd0bRJ3zNgbTk08Ls6JSlIGd30Ko41ABgClMK4Z9uU15Ih58Wd A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAL+vC1OtJXG//2dsb2JhbABZgwY7V8EqgR0WdIIlAQEBAwEBAQE3NAsQAgEIGB4QIQYLJQIEDgWHcQMJCA2/AA2GbhMEjE+BYjMHgySBFAEDlkeBbYxghUeDLYIq X-IronPort-AV: E=Sophos;i="4.97,536,1389744000"; d="scan'208";a="22822296" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-2.cisco.com with ESMTP; 24 Feb 2014 20:52:16 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1OKqGpI016628 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Feb 2014 20:52:16 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.148]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Mon, 24 Feb 2014 14:52:16 -0600 From: "Ralph Droms (rdroms)" To: Jouni Korhonen Subject: Re: Comments on draft-ietf-6man-multicast-scopes-02 Thread-Topic: Comments on draft-ietf-6man-multicast-scopes-02 Thread-Index: AQHPKO7Ub78QyOFOHUWuPF5xJUyOuZq0UKiAgBBSPgCAALRrAA== Date: Mon, 24 Feb 2014 20:52:16 +0000 Message-ID: References: <30F57851-87B7-4260-B1C0-A56681020C9B@cisco.com> <6F6D0664-A4A8-4113-B036-FAA2E742FBF2@gmail.com> In-Reply-To: <6F6D0664-A4A8-4113-B036-FAA2E742FBF2@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.68.174] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/AJCSrgYeFhU90ACah-vKPQfxEpE Cc: "draft-ietf-6man-multicast-scopes@tools.ietf.org" , IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 20:52:23 -0000 On Feb 24, 2014, at 5:06 AM 2/24/14, Jouni Korhonen wrote: >=20 >=20 > Looks good to me now. OK, thanks. - Ralph >=20 > - Jouni >=20 > On Feb 14, 2014, at 2:52 AM, Ralph Droms (rdroms) wrot= e: >=20 >> draft-ietf-6man-multicast-scopes-03.txt addresses the comment posted dur= ing the WG last call (see attached diff). >>=20 >> In my opinion, this rev of the document is ready to be sent to the IESG. >>=20 >> - Ralph >>=20 >> ------------------= -------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 From nobody Mon Feb 24 15:04:40 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3951A02CD for ; Mon, 24 Feb 2014 15:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdbSKHqAjbK8 for ; Mon, 24 Feb 2014 15:04:36 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2A63F1A01CB for ; Mon, 24 Feb 2014 15:04:36 -0800 (PST) Received: from [192.168.10.18] ([78.204.24.4]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s1ON2SL3001861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 24 Feb 2014 15:02:29 -0800 Message-ID: <530BCF83.4090500@acm.org> Date: Mon, 24 Feb 2014 15:02:27 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ole Troan , Erik Nordmark Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast References: <5305AF13.5060201@acm.org> <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org> In-Reply-To: <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;qPl8u6ed4xGYANseCY+HFQ== M;hksfvKed4xGYANseCY+HFQ== Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/FtXp_5s1gHlv0v8l0gGArA38P2Q Cc: Andrew Yourtchenko , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 23:04:37 -0000 On 2/20/14 6:43 AM, Ole Troan wrote: > > >> 4.8 seems to conflate the address assignment with DAD. Just because we might want to centralize the DAD checks doesn't imply that we want to remove the ability for the host to pick its own privacy enhanced interface-IDs to form its addresses. >> From a deployment perspective DHCPv6 is available for address assignment, but don't think we want to require that for WiFi or other links which have packet loss. (Packet loss occurs on wired networks as well, but the drop distribution is different - might happen during spanning tree reconvergence etc.) >> Note that DHCPv6 (RFC 3315) has a SHOULD for doing DAD on the addresses received from the DHCP server - needed since the server could be confused. > I'd like to explore the difference between DHCP address assignment and ND address registration a little more. > the state that is required in the network for "efficient ND", why cannot that be created and maintained by DHCP? > > there are multiple ways of dealing with DAD in this scenario, including solutions that don't require host changes. > DHCP also supports temporary addresses btw. DHCP supports RFC 4941 temporary addresses, but it doesn't support others like CGA and stable-privacy-addresses. With IA_TA the DHCP server creates the temporary address, and that approach doesn't work with other addresses that need to be client-generated for security or privacy reasons. One could envision changing DHCP to have a separate "please register this address" message and/or option, which would check against duplicates (of assigned and registered addresses) and then add it to the registered addresses in the server. But that would seem like a fair bit of new functionality in DHCP. Currently RFC 3315 separates address assignment and DAD - the client SHOULD perform DAD on an address that is assigned by the DHCP server. This separation goes back to DHCPv4 where there was a similar check (I think using ICMP echo) which I believe is there for the reason that the DHCP servers list of assigned addresses could get out of sync with the hosts. (If DAD fails the host declines the address hence will get a different one.) I don't see how we can do this without host changes even for the case of IA_NA and IA_TA DHCP assigned addresses; the hosts would need to remove the code which does the DAD check for DHCP. (And there would be additional DHCP protocol changes needed to support CGA and stable-privacy-addresses and any future address assignment scheme.) Erik From nobody Mon Feb 24 23:39:37 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757111A053B for ; Mon, 24 Feb 2014 23:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65wT_TtMZsl4 for ; Mon, 24 Feb 2014 23:39:34 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 587A21A0346 for ; Mon, 24 Feb 2014 23:39:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3349; q=dns/txt; s=iport; t=1393313974; x=1394523574; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9/Mujw/WAPwGzmad5vaUnd40q4ojn9Yz5CGmAovV6PI=; b=Y8CwxREr5n8QAFIQPcxxJdk5Y5WW36EsSySfNrqbMI3gOczmBfDvhL/z sV0Boc52MszQWBQOxONM9tgUYwKMPAy3BfaAanInr1Ke5idQXjKcbcjIw YqY0LSVJKR0kBXKqQ+Xu0KjDVYnnNkQuc+66GOMGSB5l1N5pwIo3JCv05 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAERIDFOtJXHA/2dsb2JhbABZgwg4vh2BFxYBdIN9AQEBAwEBAQFrCwULAgEIGC4nCyUCBA4FG4dhCA2+VhMEjl8zB4MjgRMEiQuPC5IUgyuBaCQ X-IronPort-AV: E=Sophos;i="4.97,863,1389744000"; d="scan'208";a="303263405" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 25 Feb 2014 07:39:33 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1P7dXUH029768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 07:39:33 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.84]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 01:39:33 -0600 From: "Pascal Thubert (pthubert)" To: Erik Nordmark Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Topic: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Index: AQHPLg20SjVxfDziP0SiLTMeBLFIcJrFDYrPgACPzGs= Date: Tue, 25 Feb 2014 07:39:32 +0000 Message-ID: References: <5305AF13.5060201@acm.org> <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org>, <530BCF83.4090500@acm.org> In-Reply-To: <530BCF83.4090500@acm.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/4p0IJIgM2NNNOVaj2asr5y7sxDM Cc: Erik Nordmark , "Andrew Yourtchenko \(ayourtch\)" , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 07:39:36 -0000 And we need to remember that the assignment is just one component of the li= fecycle of an address.=20 When the client stops using an address, or moves the address somewhere else= in the fabric, there is a need to update the network support that defends = the address and proxies. Cheers, Pascal > Le 25 f=E9vr. 2014 =E0 00:04, "Erik Nordmark" a =E9cri= t : >=20 >> On 2/20/14 6:43 AM, Ole Troan wrote: >> >>=20 >>> 4.8 seems to conflate the address assignment with DAD. Just because we = might want to centralize the DAD checks doesn't imply that we want to remov= e the ability for the host to pick its own privacy enhanced interface-IDs t= o form its addresses. >>> From a deployment perspective DHCPv6 is available for address assignmen= t, but don't think we want to require that for WiFi or other links which ha= ve packet loss. (Packet loss occurs on wired networks as well, but the drop= distribution is different - might happen during spanning tree reconvergenc= e etc.) >>> Note that DHCPv6 (RFC 3315) has a SHOULD for doing DAD on the addresses= received from the DHCP server - needed since the server could be confused. >> I'd like to explore the difference between DHCP address assignment and N= D address registration a little more. >> the state that is required in the network for "efficient ND", why cannot= that be created and maintained by DHCP? >>=20 >> there are multiple ways of dealing with DAD in this scenario, including = solutions that don't require host changes. >> DHCP also supports temporary addresses btw. > DHCP supports RFC 4941 temporary addresses, but it doesn't support others= like CGA and stable-privacy-addresses. With IA_TA the DHCP server creates = the temporary address, and that approach doesn't work with other addresses = that need to be client-generated for security or privacy reasons. >=20 > One could envision changing DHCP to have a separate "please register this= address" message and/or option, which would check against duplicates (of a= ssigned and registered addresses) and then add it to the registered address= es in the server. But that would seem like a fair bit of new functionality = in DHCP. >=20 > Currently RFC 3315 separates address assignment and DAD - the client SHOU= LD perform DAD on an address that is assigned by the DHCP server. This sepa= ration goes back to DHCPv4 where there was a similar check (I think using I= CMP echo) which I believe is there for the reason that the DHCP servers lis= t of assigned addresses could get out of sync with the hosts. (If DAD fails= the host declines the address hence will get a different one.) >=20 > I don't see how we can do this without host changes even for the case of = IA_NA and IA_TA DHCP assigned addresses; the hosts would need to remove the= code which does the DAD check for DHCP. (And there would be additional DHC= P protocol changes needed to support CGA and stable-privacy-addresses and a= ny future address assignment scheme.) >=20 > Erik >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue Feb 25 00:41:23 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37ED81A01D9 for ; Tue, 25 Feb 2014 00:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.313 X-Spam-Level: ** X-Spam-Status: No, score=2.313 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-l3l3MXccAA for ; Tue, 25 Feb 2014 00:41:20 -0800 (PST) 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 1616D1A0194 for ; Tue, 25 Feb 2014 00:41:19 -0800 (PST) Received: from [98.139.212.150] by nm28.bullet.mail.bf1.yahoo.com with NNFMP; 25 Feb 2014 08:41:19 -0000 Received: from [98.139.212.197] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 25 Feb 2014 08:41:18 -0000 Received: from [127.0.0.1] by omp1006.mail.bf1.yahoo.com with NNFMP; 25 Feb 2014 08:41:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 907690.44051.bm@omp1006.mail.bf1.yahoo.com Received: (qmail 66663 invoked by uid 60001); 25 Feb 2014 08:41:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1393317678; bh=R87kgMk1cGAFuthpBDpvDiUC2GNHOFpSJLH4WCIfd0Q=; 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=NhV28Q34+f5djqJwjxG6vrjjJOSi0Klo1Q8PXc57dKHkRjM4OyjWuSudaUKw3cMm2W5mFDQ8SZ5XLBalfZTYtYf4ii3iqraf6L3hOK7oLuB2VRYS9zg47/yiCGuj+25pU5HozFFvEVJ2B9KpIsASB2REYUaEnr+kVNHaK1Vg+Jg= 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=f1JRwjOKe5EY/yY/b4LPAsQp4pfM4VzL35eQ1wpqWwcg59jdV+HEhxaeOQmkFi+jvDwtArSDEcKeTvqbt0689itLej+fLbKxJ9eC1bR7ORu48iJavxx3jTrdMlqL+UxBVzNCGLKT8JhrjCzivW5WXJdwxXKPx58AKCAp+poGc1I=; X-YMail-OSG: 3yA4mGAVM1lRYij3Y3mcF1edf0Ws4TCY1573e1Jt5EI1ftY MtwsYt729wyNj3RA7P7dZFOd_1G0GyyHwAowzhSQPH1X_96nfxOoyTy01Tun 2AZUjNF37VBtjenMJsK9kb6a_fEp.z_62ckzZIaKpkVGqPkQwKD2nNN5PUVn iDC8GoQlFbDS8UhMszLxkfwtVbHEHYmDL5q.kU3Keg56NPf78mJ9O1IICZG0 IIBTRcTeKCRMCTwqGG2WB76qud6J5UwSC829U_XK2sNT6NOPZ1n.6DQzEKGw 5MxXaJ.pWPYt1cq1tGhUGIkndxcFoqS4tYERMwVsrOsiru4opxahBiG69umF FsxFHzeZpfkXx0O6jbZLqUdJxk6JBt4YkHWW8b316o8cDXlEp.yLS.UzqU5F U6U0fqmhCECaSC6BRjrYOuP4rPjyw2Buw8gxZHBDNcLxxSXVJOUkRNtOdrvX hPUGRxrgaUImCZs2DItfsOfNVAOA86NjYsd70nsXCtwRPglnRC.NdwDAdanF _Oxp0xbL9r.krq1TjlAG0sR2v5cz4EROTXBi4vxBPL9do8Gzcr8FaRDZS2TM GEnNducnri4r9C0hILzxD337PIlzHmsjKAHVzlYkZ2ZdxFMSaDT0cA0PXnc1 wy548vCvogJARtKI01EoFl1YntNn0xQxrWjRjw3A6jNBdfvxVpdj2LFt3xiX pCSjSm1rthhDZTHhTRq_Z70yJrCoRx264R85V4wPZnw-- Received: from [150.101.221.237] by web162204.mail.bf1.yahoo.com via HTTP; Tue, 25 Feb 2014 00:41:18 PST X-Rocket-MIMEInfo: 002.001, SGksCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206IExpdWJpbmcgKExlbykgPGxlby5saXViaW5nQGh1YXdlaS5jb20.Cj4gVG86IElQdjYgSVB2NiBMaXN0IDxpcHY2QGlldGYub3JnPgo.IENjOiAKPiBTZW50OiBNb25kYXksIDI0IEZlYnJ1YXJ5IDIwMTQgODo1NyBQTQo.IFN1YmplY3Q6IENsZWFyaW5nIHRoZSBhbWJpZ3VpdHkgaW4gREhDUHY2L1NMQUFDIGludGVyYWN0aW9uLS8vRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGl1LTZtYW4tZGhjcHY2LXNsYWEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8535C2@nkgeml506-mbx.china.huawei.com> Message-ID: <1393317678.39795.YahooMailNeo@web162204.mail.bf1.yahoo.com> Date: Tue, 25 Feb 2014 00:41:18 -0800 (PST) From: Mark ZZZ Smith Subject: Re: Clearing the ambiguity in DHCPv6/SLAAC interaction-//FW: New Version Notification for draft-liu-6man-dhcpv6-slaac-implementation-guide-00.txt To: "Liubing \(Leo\)" , IPv6 IPv6 List In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8535C2@nkgeml506-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/fcZ39Oa0ObdecqJ0ku76xj0IVq8 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 25 Feb 2014 08:41:22 -0000 Hi,=0A=0A=0A----- Original Message -----=0A> From: Liubing (Leo) =0A> To: IPv6 IPv6 List =0A> Cc: =0A> Sent: Mo= nday, 24 February 2014 8:57 PM=0A> Subject: Clearing the ambiguity in DHCPv= 6/SLAAC interaction-//FW: New Version Notification for draft-liu-6man-dhcpv= 6-slaac-implementation-guide-00.txt=0A> =0A> Hi Dear all,=0A> =0A> We've di= scussed the DHCPv6/SLAAC address-config problems in 6man a couple of =0A> t= imes before. =0A> In summary, the problem is regarding with the ambiguity o= n interpreting the M =0A> flag and O flag in ND messages. Different operati= ng systems' behavior has =0A> varied on interpreting the flags, especially = when flags are in transition.=0A> =0A> In last ietf, the draft discussing t= he issues was adopted by v6ops to be a =0A> problem statement document (dra= ft-ietf-v6ops-dhcpv6-slaac-problem).=0A> People from OPS area agreed that t= he problems need to be solved, and suggested =0A> us to initial another wor= k in 6man to discuss how to deal with the issues. =0A> =0A> So below is jus= t the draft, it is to specify the proper behavior when the hosts =0A> inter= preting the relevant flags (A flag, M flag and O flag) in different states.= =0A> =0A> Please have a review, and comment whether you agree the approache= s.=0A> And we're open to discussing other proposals to clear the ambiguity = (e.g. =0A> revising the relevant specification in RFC4861/4862), so please = feel free to =0A> comment.=0A>=A0=0A=0AI think it is right to point out tha= t address lifetime expiry is the only mechanism to be used to expire addres= ses, rather than whether or not the address configuration method also conti= nues to be active. Specific to DHCPv6, it may be worth referencing this tex= t in RFC3315, to further describe that address expiry is based only on life= time:=0A=0A"If the client receives no responses before the message transmis= sion=0A=A0 =A0process terminates, as described in section 14, the client SH= OULD=0A=A0 =A0continue to use any IP addresses, using the last known lifeti= mes for=0A=A0 =A0those addresses, and SHOULD continue to use any other prev= iously=0A=A0 =A0obtained configuration parameters."=0A=0A=0AIt might be wor= th pointing out that if addresses are to be actively expired via an address= configuration method, then the technique to use would be to "reconfigure" = the addresses with low or zero valid lifetime, letting the address expiry m= ethod using the lifetime value then expire them.=0A=0A"However, for the imp= lementation, making DHCPv6 initialing totally=0A=A0 =A0depend on RA message= s is more or less fragile since DHCPv6-only-=0A=A0 =A0without-RA might beco= me a valid case in the future or some special=0A=A0 =A0scenarios. So it is = recommended for implementers to take into account=0A=A0 =A0the cases that R= As are absent. The DHCPv6 protocol state machine=0A=A0 =A0should support DH= CPv6 be initiated after a timeslot of RAs absent."=0A=0AI think it would be= better to wait until "DHCPv6-only-without-RA" is specified before making t= his recommendation. I don't think there is anything which provides advice o= n how to implement it. For example, I'd think it would be better to initiat= e RA RS and DHCPv6 Solicit at the same time, rather than waiting for RA RSe= s to timeout, as it would provide the better end-user experience.=0A=0AHowe= ver, initiating RA RS and DHCPv6 Solicit at the same time would then imply = that the the RA M & O bits have no value. DHCPv6 clients would then have to= always assume they need to perform a stateful DHCPv6 transaction, even tho= ugh the chosen methods for the link might be SLAAC + stateless DHCPv6 for n= on-address information. RFC3315 is a bit ambiguous as to what to do if the = DHCPv6 server does not have any addresses to give to the client:=0A=0A=0A"I= f the client receives no addresses in=0A=A0 =A0any of the IAs, it may eithe= r try another server (perhaps restarting=0A=A0 =A0the DHCP server discovery= process) or use the Information-request=0A=A0 =A0message to obtain other c= onfiguration information only."=0A=0AIn the context of performing RA RS and= DHCPv6 Solicit in parallel, it is hard to know which is the better choice = (+). On the one hand, the DHCPv6 server not having addresses available coul= d indicate it is a stateless only server, so the Information-request proced= ure should be performed. OTOH, perhaps the stateful DHCPv6 server selected = by the client ran out of addresses, and another stateful DHCPv6 server migh= t be available with addresses. If only there were some bits somewhere that = would indicate what the DHCPv6 client should do ...=0A=0AThese ambiguities = are just from me thinking about it for half an hour or so. I suspect there = would be a lot more. The "Less is More" and other principles from RFC5505 c= ome to mind.=0A=0A=0ARegards,=0AMark.=0A=0A(+ but certainly not this sort o= f behaviour -=A0http://lists.si6networks.com/pipermail/ipv6hackers/2014-Feb= ruary/001501.html)=0A=0A> Many thanks!=0A> =0A> Best regards,=0A> Bing=0A> = =0A> =0A> -----Original Message-----=0A> From: internet-drafts@ietf.org [ma= ilto:internet-drafts@ietf.org] =0A> Sent: Friday, February 14, 2014 6:09 PM= =0A> To: Liubing (Leo); Ron Bonica; Liubing (Leo); Ron Bonica=0A> Subject: = New Version Notification for =0A> draft-liu-6man-dhcpv6-slaac-implementatio= n-guide-00.txt=0A> =0A> =0A> A new version of I-D, draft-liu-6man-dhcpv6-sl= aac-implementation-guide-00.txt=0A> has been successfully submitted by Bing= Liu and posted to the IETF repository.=0A> =0A> Name:=A0=A0=A0 =A0=A0=A0 d= raft-liu-6man-dhcpv6-slaac-implementation-guide=0A> Revision:=A0=A0=A0 00= =0A> Title:=A0=A0=A0 =A0=A0=A0 DHCPv6/SLAAC Interaction Implementation Guid= ance=0A> Document date:=A0=A0=A0 2014-02-14=0A> Group:=A0=A0=A0 =A0=A0=A0 I= ndividual Submission=0A> Pages:=A0=A0=A0 =A0=A0=A0 6=0A> URL:=A0 =A0 =A0 = =A0 =A0 =A0 =0A> http://www.ietf.org/internet-drafts/draft-liu-6man-dhcpv6-= slaac-implementation-guide-00.txt=0A> Status:=A0 =A0 =A0 =A0 =0A> https://d= atatracker.ietf.org/doc/draft-liu-6man-dhcpv6-slaac-implementation-guide/= =0A> Htmlized:=A0 =A0 =A0 =0A> http://tools.ietf.org/html/draft-liu-6man-dh= cpv6-slaac-implementation-guide-00=0A> =0A> =0A> Abstract:=0A> =A0 ND and = DHCPv6 protocols could have some interaction on address=0A> =A0 provisioni= ng with the A, M, and O flags defined in ND protocol. But=0A> =A0 the rele= vant standard definitions of the flags contain ambiguity, so=0A> =A0 that = current implementations in operating systems have varied on=0A> =A0 interp= reting the flags. The variation might impact real network=0A> =A0 operatio= ns, so this document aims to provide some guidance on what=0A> =A0 should = be the proper implementation on the interaction behavior.=0A> =0A> =0A> =0A= > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =0A> =A0 =0A> =0A> =0A> Please note that it may take a couple = of minutes from the time of submission =0A> until the htmlized version and = diff are available at tools.ietf.org.=0A> =0A> The IETF Secretariat=0A> =0A= > --------------------------------------------------------------------=0A> = IETF IPv6 working group mailing list=0A> ipv6@ietf.org=0A> Administrative R= equests: https://www.ietf.org/mailman/listinfo/ipv6=0A> -------------------= -------------------------------------------------=0A> From nobody Tue Feb 25 00:57:55 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC80C1A0464 for ; Tue, 25 Feb 2014 00:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaBgjeO5nFVV for ; Tue, 25 Feb 2014 00:57:50 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7167F1A0388 for ; Tue, 25 Feb 2014 00:57:50 -0800 (PST) Received: from [192.168.10.18] ([78.204.24.4]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s1P8vfjE015944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Feb 2014 00:57:42 -0800 Message-ID: <530C5B06.5090609@acm.org> Date: Tue, 25 Feb 2014 00:57:42 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Mark ZZZ Smith , "Liubing (Leo)" , IPv6 IPv6 List Subject: Re: Clearing the ambiguity in DHCPv6/SLAAC interaction-//FW: New Version Notification for draft-liu-6man-dhcpv6-slaac-implementation-guide-00.txt References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8535C2@nkgeml506-mbx.china.huawei.com> <1393317678.39795.YahooMailNeo@web162204.mail.bf1.yahoo.com> In-Reply-To: <1393317678.39795.YahooMailNeo@web162204.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;ZLgZ4vqd4xG+NugyCY+HFQ== M;SD264vqd4xG+NugyCY+HFQ== Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/BACfWrn-KAbiPXQhVe8LVsjDiG0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 08:57:52 -0000 On 2/25/14 12:41 AM, Mark ZZZ Smith wrote: > > I think it is right to point out that address lifetime expiry is the only mechanism to be used to expire addresses, rather than whether or not the address configuration method also continues to be active. Specific to DHCPv6, it may be worth referencing this text in RFC3315, to further describe that address expiry is based only on lifetime: > > "If the client receives no responses before the message transmission > process terminates, as described in section 14, the client SHOULD > continue to use any IP addresses, using the last known lifetimes for > those addresses, and SHOULD continue to use any other previously > obtained configuration parameters." > > > It might be worth pointing out that if addresses are to be actively expired via an address configuration method, then the technique to use would be to "reconfigure" the addresses with low or zero valid lifetime, letting the address expiry method using the lifetime value then expire them. That is the behavior we have today. Sounds like this needs to be made more explicit. > > "However, for the implementation, making DHCPv6 initialing totally > depend on RA messages is more or less fragile since DHCPv6-only- > without-RA might become a valid case in the future or some special > scenarios. So it is recommended for implementers to take into account > the cases that RAs are absent. The DHCPv6 protocol state machine > should support DHCPv6 be initiated after a timeslot of RAs absent." > > I think it would be better to wait until "DHCPv6-only-without-RA" is specified before making this recommendation. I don't think there is anything which provides advice on how to implement it. For example, I'd think it would be better to initiate RA RS and DHCPv6 Solicit at the same time, rather than waiting for RA RSes to timeout, as it would provide the better end-user experience. This use case (DHCP but no routers) was discussed in the DHC WG a long time ago. (If I don't misremember it even had a name - "the dentist office".) The idea was that some networks wouldn't even be connected to the network, and be quite small. The answer from back then was that if there wasn't a router, who would configure a DHCP server. Today everything seems to be connected - even if in some cases it is a private network and not the public Internet. Hence I question the utility of changing the protocols and implementations to handle a case when there is no router. Erik > > However, initiating RA RS and DHCPv6 Solicit at the same time would then imply that the the RA M & O bits have no value. DHCPv6 clients would then have to always assume they need to perform a stateful DHCPv6 transaction, even though the chosen methods for the link might be SLAAC + stateless DHCPv6 for non-address information. RFC3315 is a bit ambiguous as to what to do if the DHCPv6 server does not have any addresses to give to the client: > > > "If the client receives no addresses in > any of the IAs, it may either try another server (perhaps restarting > the DHCP server discovery process) or use the Information-request > message to obtain other configuration information only." > > In the context of performing RA RS and DHCPv6 Solicit in parallel, it is hard to know which is the better choice (+). On the one hand, the DHCPv6 server not having addresses available could indicate it is a stateless only server, so the Information-request procedure should be performed. OTOH, perhaps the stateful DHCPv6 server selected by the client ran out of addresses, and another stateful DHCPv6 server might be available with addresses. If only there were some bits somewhere that would indicate what the DHCPv6 client should do ... > > These ambiguities are just from me thinking about it for half an hour or so. I suspect there would be a lot more. The "Less is More" and other principles from RFC5505 come to mind. > > > Regards, > Mark. > > (+ but certainly not this sort of behaviour - http://lists.si6networks.com/pipermail/ipv6hackers/2014-February/001501.html) > >> Many thanks! >> >> Best regards, >> Bing >> >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Friday, February 14, 2014 6:09 PM >> To: Liubing (Leo); Ron Bonica; Liubing (Leo); Ron Bonica >> Subject: New Version Notification for >> draft-liu-6man-dhcpv6-slaac-implementation-guide-00.txt >> >> >> A new version of I-D, draft-liu-6man-dhcpv6-slaac-implementation-guide-00.txt >> has been successfully submitted by Bing Liu and posted to the IETF repository. >> >> Name: draft-liu-6man-dhcpv6-slaac-implementation-guide >> Revision: 00 >> Title: DHCPv6/SLAAC Interaction Implementation Guidance >> Document date: 2014-02-14 >> Group: Individual Submission >> Pages: 6 >> URL: >> http://www.ietf.org/internet-drafts/draft-liu-6man-dhcpv6-slaac-implementation-guide-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-liu-6man-dhcpv6-slaac-implementation-guide/ >> Htmlized: >> http://tools.ietf.org/html/draft-liu-6man-dhcpv6-slaac-implementation-guide-00 >> >> >> Abstract: >> ND and DHCPv6 protocols could have some interaction on address >> provisioning with the A, M, and O flags defined in ND protocol. But >> the relevant standard definitions of the flags contain ambiguity, so >> that current implementations in operating systems have varied on >> interpreting the flags. The variation might impact real network >> operations, so this document aims to provide some guidance on what >> should be the proper implementation on the interaction behavior. >> >> >> >> >> >> >> >> 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 >> >> -------------------------------------------------------------------- >> 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 nobody Tue Feb 25 01:12:30 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907601A03C3 for ; Tue, 25 Feb 2014 01:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.202 X-Spam-Level: * X-Spam-Status: No, score=1.202 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YI2EfT_LCuE for ; Tue, 25 Feb 2014 01:12:25 -0800 (PST) Received: from nm29-vm1.bullet.mail.bf1.yahoo.com (nm29-vm1.bullet.mail.bf1.yahoo.com [98.139.213.144]) by ietfa.amsl.com (Postfix) with ESMTP id E1ADA1A03A4 for ; Tue, 25 Feb 2014 01:12:24 -0800 (PST) Received: from [98.139.212.149] by nm29.bullet.mail.bf1.yahoo.com with NNFMP; 25 Feb 2014 09:12:24 -0000 Received: from [98.139.212.215] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 25 Feb 2014 09:12:24 -0000 Received: from [127.0.0.1] by omp1024.mail.bf1.yahoo.com with NNFMP; 25 Feb 2014 09:12:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 664920.62741.bm@omp1024.mail.bf1.yahoo.com Received: (qmail 90077 invoked by uid 60001); 25 Feb 2014 09:12:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1393319543; bh=aGJuXfOllxllYwrYJgfZq0h/IrlNyFzkF5TS0QzAugg=; 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=eQAgJz3TjVyAUTJ/DgZoyIpvTNPoa69Sied6GEbmQ8WJJovWsHihXEsVYGQJJbbS4qsNOYdt2qtoGp5evYj49GyAQc4UigA9XyEVJ9VvHAYNVyzD+XN7swBEw9qfFKGMSL4bNhqI4kK9cI2+M/ZyP6jgCBW0DLsTFG6MttOFq98= 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=4D5fMwdKrtB4FElQtkdbIeGiwe1/NrEAsaH6xGaHMFzf9fuykxM2nOPmb0p0EGPErkr1V1j9Og6+tvAOgsfpXVZJ91VitVtFiC/qKJv1DTHlD9CiMFd65lHVzjHY9OFZh0v8oathSJwwMwrUkKQ0cDgoyVIIkvrmiGvPDakg34A=; X-YMail-OSG: qhk2cNEVM1m7OQFMxyxnZe05MGzfpCHhxkxg9TU38mjyeXZ sX4yEsKKOUppbAoA3Fynn4C4GhetZf5c5Qshf.oZXLJ_Z0FT1k07MCh5rzdM 5mkO1Jfe0w0XJpeYhZybw2IRzuw4lq2UL57CuyLIrczQxKWs8D4xfqBl0mFS cUcynVECWjA43Ir.YAUzZaOlkp_1ZzjvO_m9NBXXw9Yk3_LXPqFzOEcilXGj SHNYYdKL4BKaoGV_ma7unNEoov8X7zuoJ4UZ.iV4Mq.8ZMpJjbxTEt23qTJr OuaOx0yHk8zrPoKli2xL_Fxwv1Ki9W96ukGmpEyAI67A94fO9qyFSRlY.osh kYZ99KSmX_CFavHeglLNiLwRbJxrd2AFqLhmN8FLGjHcX2J9xKJX_pf6sXsp dkrWxyR2N8LQfm8321ydaq.TButd8RTfMg.EeOxtaGsYqoo_O14EyZovrJgN 3aEh3VlWPdSeuEd2FtXmhXNh09C9qqIQt9LtkvBMQTjcFh128o3lfFlzeDkJ PPY0e21T_EsYNvEZlRI5MrGguk9Sm.t9wM5_G09YGZ2npcuM8QdS9GDbti1N WuAFUxGODKmcLoJ_bm0dRdo.aSQ-- Received: from [150.101.221.237] by web162201.mail.bf1.yahoo.com via HTTP; Tue, 25 Feb 2014 01:12:23 PST X-Rocket-MIMEInfo: 002.001, QcKgCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206IEVyaWsgTm9yZG1hcmsgPG5vcmRtYXJrQGFjbS5vcmc.Cj4gVG86IE9sZSBUcm9hbiA8b3Ryb2FuQGVtcGxveWVlcy5vcmc.OyBFcmlrIE5vcmRtYXJrIDxub3JkbWFya0BhY20ub3JnPgo.IENjOiBBbmRyZXcgWW91cnRjaGVua28gPGF5b3VydGNoQGNpc2NvLmNvbT47IDZtYW4gV0cgPGlwdjZAaWV0Zi5vcmc.Cj4gU2VudDogVHVlc2RheSwgMjUgRmVicnVhcnkgMjAxNCAxMDowMiBBTQo.IFN1YmplY3Q6IFJlOiBDb21tZW50cyBvbiABMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <5305AF13.5060201@acm.org> <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org> <530BCF83.4090500@acm.org> Message-ID: <1393319543.97599.YahooMailNeo@web162201.mail.bf1.yahoo.com> Date: Tue, 25 Feb 2014 01:12:23 -0800 (PST) From: Mark ZZZ Smith Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast To: Erik Nordmark , Ole Troan In-Reply-To: <530BCF83.4090500@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/zra6LDgABXGpc4FsXvVf2_miDjw Cc: Andrew Yourtchenko , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 25 Feb 2014 09:12:26 -0000 A=A0=0A=0A=0A----- Original Message -----=0A> From: Erik Nordmark =0A> To: Ole Troan ; Erik Nordmark =0A> Cc: Andrew Yourtchenko ; 6man WG =0A> Sent: Tuesday, 25 February 2014 10:02 AM=0A> Subject: Re: Comme= nts on draft-yourtchenko-colitti-nd-reduce-multicast=0A> =0A> On 2/20/14 6:= 43 AM, Ole Troan wrote:=0A>> =0A>> =0A>>> 4.8 seems to conflate = the address assignment with DAD. Just because we =0A> might want to central= ize the DAD checks doesn't imply that we want to remove =0A> the ability fo= r the host to pick its own privacy enhanced interface-IDs to form =0A> its = addresses.=0A>>> =A0 From a deployment perspective DHCPv6 is available for = address =0A> assignment, but don't think we want to require that for WiFi o= r other links =0A> which have packet loss. (Packet loss occurs on wired net= works as well, but the =0A> drop distribution is different - might happen d= uring spanning tree reconvergence =0A> etc.)=0A=0A=0A=0A> =0A> Curren= tly RFC 3315 separates address assignment and DAD - the client =0A> SHOULD = perform DAD on an address that is assigned by the DHCP server. =0A> This se= paration goes back to DHCPv4 where there was a similar check (I =0A> think = using ICMP echo) which I believe is there for the reason that the =0A> DHCP= servers list of assigned addresses could get out of sync with the =0A> hos= ts. (If DAD fails the host declines the address hence will get a =0A> diffe= rent one.)=0A> =0A> I don't see how we can do this without host changes eve= n for the case of =0A> IA_NA and IA_TA DHCP assigned addresses; the hosts w= ould need to remove =0A> the code which does the DAD check for DHCP. (And t= here would be =0A> additional DHCP protocol changes needed to support CGA a= nd =0A> stable-privacy-addresses and any future address assignment scheme.)= =0A=0AI think a DAD Proxy is what you're looking for -=0A=0ARFC6957 - "Dupl= icate Address Detection Proxy."=0A=0A=0AMore broadly though, I think a meth= od that supports any forms of multicast from a host to the other hosts on t= he link, hair-pinned through the upstream router(s), would be better. It wo= uld support DAD operation, and would also support other multicasts from hos= ts, such as Multicast DNS for device (printer) discovery, and SSDP for DLNA= server discovery.=A0=0A=0AI've been thinking about this scenario for quite= a while, and it seems to me that there are fundamentally two approaches to= this problem.=A0=0A=0AThe first one involves minimal or no changes to the = hosts (e.g., an optional RA PIO for link-local flagged as off-link and that= is it, as a host local optimisation instead of ND proxy for link-local add= resses), and emulate functions at the upstream router(s) that won't work be= cause of host to host isolation within the link.=0A=0AThe other one involve= s wholesale changes to the hosts, and I think that would mean fully impleme= nting an IPv6 NBMA subnet, perhaps with an RA option to announce to the hos= ts that the link is operating in NBMA mode, and the address(es) of the MARS= cluster.=A0=0A=0AThe NBMA method would be convenient, as all these sorts o= f multicast/link-local etc. issues are already dealt with. However, I think= wholesale changes to hosts to support it are probably infeasible.=0A=0A=0A= Regards,=0AMark.=0A=0A=0A=0A=0A> =A0 =A0 Erik=0A> =0A> =0A> ---------------= -----------------------------------------------------=0A> IETF IPv6 working= group mailing list=0A> ipv6@ietf.org=0A> Administrative Requests: https://= www.ietf.org/mailman/listinfo/ipv6=0A> ------------------------------------= --------------------------------=0A> From nobody Tue Feb 25 01:28:54 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB17B1A0660 for ; Tue, 25 Feb 2014 01:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.252 X-Spam-Level: X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SItLNJaZ_s34 for ; Tue, 25 Feb 2014 01:28:41 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id BCA1A1A065F for ; Tue, 25 Feb 2014 01:28:41 -0800 (PST) Received: from dhcp-10-61-104-154.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 6363E6107; Tue, 25 Feb 2014 01:28:37 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_0BEC8FE5-F9B4-49C1-829A-3E6E6580A485"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast From: Ole Troan In-Reply-To: <530BCF83.4090500@acm.org> Date: Tue, 25 Feb 2014 10:28:35 +0100 Message-Id: References: <5305AF13.5060201@acm.org> <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org> <530BCF83.4090500@acm.org> To: Erik Nordmark X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/XbAZmyQc-0uqJJMBWOXbJWQGO40 Cc: Andrew Yourtchenko , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 09:28:47 -0000 --Apple-Mail=_0BEC8FE5-F9B4-49C1-829A-3E6E6580A485 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Erik, disclaimer: let me first be clear about the context I'm discussing this in. please don't interpret the fact that I have taken the position of = 'defending' DHCP to mean that I'm proposing that as the solution. I just = want to explore DHCP and understand the short-comings, and what = unresolved problems there are. and I reserve the right to change my mind = at any point. ;-) >> >>=20 >>> 4.8 seems to conflate the address assignment with DAD. Just because = we might want to centralize the DAD checks doesn't imply that we want to = remove the ability for the host to pick its own privacy enhanced = interface-IDs to form its addresses. >>> =46rom a deployment perspective DHCPv6 is available for address = assignment, but don't think we want to require that for WiFi or other = links which have packet loss. (Packet loss occurs on wired networks as = well, but the drop distribution is different - might happen during = spanning tree reconvergence etc.) >>> Note that DHCPv6 (RFC 3315) has a SHOULD for doing DAD on the = addresses received from the DHCP server - needed since the server could = be confused. >> I'd like to explore the difference between DHCP address assignment = and ND address registration a little more. >> the state that is required in the network for "efficient ND", why = cannot that be created and maintained by DHCP? >>=20 >> there are multiple ways of dealing with DAD in this scenario, = including solutions that don't require host changes. >> DHCP also supports temporary addresses btw. > DHCP supports RFC 4941 temporary addresses, but it doesn't support = others like CGA and stable-privacy-addresses. With IA_TA the DHCP server = creates the temporary address, and that approach doesn't work with other = addresses that need to be client-generated for security or privacy = reasons. >=20 > One could envision changing DHCP to have a separate "please register = this address" message and/or option, which would check against = duplicates (of assigned and registered addresses) and then add it to the = registered addresses in the server. But that would seem like a fair bit = of new functionality in DHCP. RFC3315 says: The client MAY include addresses in the IAs as a hint to the server = about addresses for which the client has a preference. that's not too far off from the ND register semantics. in both cases the = final say of which address the host can used is moved to the network. > Currently RFC 3315 separates address assignment and DAD - the client = SHOULD perform DAD on an address that is assigned by the DHCP server. = This separation goes back to DHCPv4 where there was a similar check (I = think using ICMP echo) which I believe is there for the reason that the = DHCP servers list of assigned addresses could get out of sync with the = hosts. (If DAD fails the host declines the address hence will get a = different one.) >=20 > I don't see how we can do this without host changes even for the case = of IA_NA and IA_TA DHCP assigned addresses; the hosts would need to = remove the code which does the DAD check for DHCP. (And there would be = additional DHCP protocol changes needed to support CGA and = stable-privacy-addresses and any future address assignment scheme.) are there two issues here? 1) DAD detecting a duplicate address 2) DAD wasting bandwidth and energy on a WIFI link, DAD is sent L2 unicast to the AP. then the AP is = expected to forward that packet as L2 multicast back onto the link. if = we assume some smarts on the AP, then it doesn't have to send the packet = back out on the wire, but only bridge it up to router(s) for example. = (this isn't as far fetched as it seems, there are deployed products = doing this already). given all knowing state in the network, then collisions shouldn't = happen. if the network suspected it had lost state, it could try to = resolve the address on the link before assigning the address to the = host. leaving the host unchanged in this scheme only leaves us with the = problem of the sleeping host waking up at ever beacon with a DTIM = indication. since there wouldn't be a multicast message, it wouldn't = have to stay awake actually waiting for a frame. to conclude, if my understanding is correct (which it may very well not = be, since I haven't really understood how 802.11 works before now), then = DAD isn't a big issue. it can be solved (and is in deployed products) on = the AP multicast handling. we could of course also specify in a new IPv6 over foo document that DAD = attempts =3D 0 on these links, or perhaps better add a signal in RAs. cheers, Ole --Apple-Mail=_0BEC8FE5-F9B4-49C1-829A-3E6E6580A485 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 iQEcBAEBCgAGBQJTDGJDAAoJEFuJXizso86gBb0IAJ0avhxZrsPtWWKVgSdtrVaL W0bQ1a2ZBn1IheV6Bpmc4+ZwVNBRVmQfTWvQ1hOPQz1g5nJaPe1bzJVIf3FM3PcV qfFhmO04KhHl9SwbY0geWDNzYskvWjQ9qOgrmxpx7J8JN1fRUFsBem//1+5O3WcX gt9VcSc4Z5qBSC84yJe1ZmVwOg/vJT/CR4RFWdk7iVNPHsV1t10EGOQxT+nwrMtm +5u2rJReRH0+ydRSX/mAYUJY8GC8BLe7IXGn/sDMyGcGSSnOwB9W0rYnd8nGsQh6 8hci9ZvU/wB72IJagVWSxqLq+gPSOGVoxVcxvrRyourlEM3uGLFlNMT8/4dIerI= =JW1L -----END PGP SIGNATURE----- --Apple-Mail=_0BEC8FE5-F9B4-49C1-829A-3E6E6580A485-- From nobody Tue Feb 25 01:31:19 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554A71A0657 for ; Tue, 25 Feb 2014 01:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ip5WF8sXXjnC for ; Tue, 25 Feb 2014 01:31:13 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 65E7D1A0663 for ; Tue, 25 Feb 2014 01:31:12 -0800 (PST) Received: from dhcp-10-61-104-154.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 23BB360D8; Tue, 25 Feb 2014 01:31:08 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_E17D059A-40F0-4878-9E42-757BB18A4BF3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast From: Ole Troan In-Reply-To: Date: Tue, 25 Feb 2014 10:31:06 +0100 Message-Id: <1657A615-4C3F-4C59-9A87-05B78905F264@employees.org> References: <5305AF13.5060201@acm.org> <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org>, <530BCF83.4090500@acm.org> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/3HwhTpdfXCD8IRy5Q7Fb8fYMB44 Cc: Erik Nordmark , Andrew Yourtchenko , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 09:31:16 -0000 --Apple-Mail=_E17D059A-40F0-4878-9E42-757BB18A4BF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Pascal, > And we need to remember that the assignment is just one component of = the lifecycle of an address.=20 >=20 > When the client stops using an address, or moves the address somewhere = else in the fabric, there is a need to update the network support that = defends the address and proxies. why isn't that: SOLICIT, CONFIRM, RENEW, REBIND, RELEASE? cheers, Ole without hat. --Apple-Mail=_E17D059A-40F0-4878-9E42-757BB18A4BF3 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 iQEcBAEBCgAGBQJTDGLaAAoJEFuJXizso86gRVQH/2aTKiT+NgXKALXYODqHLoEJ nIqTkedCbEC3oVYJKS3LQPU25/9zktdA+Z/f6g+SKSiwZkzoIeKAbm8IntGvck/B 6jVveCJHEKP+rNGaoV9o6ecQIN/gxgGbAV2vIrD8MguF1YtE49f7NNcnn7unOoV4 fZnR7IHlUYtv3bRW6ayrVX6KAfHIp9KJUnZG9Agmxf5vh1JRMP6T3r9Up4RMlC46 4cM9GCSDjb5RKSjpMZtRTsDmuqGum9atda4KzT2R1Mi76NO+7VD1d8kudGfx3pKk vAYx35+Y86Eyg+V1ouRmcOmRShMubnYDTOlU35bmuxIj0wrSW9RlSaI4OEFYsBw= =Ze6Y -----END PGP SIGNATURE----- --Apple-Mail=_E17D059A-40F0-4878-9E42-757BB18A4BF3-- From nobody Tue Feb 25 03:04:50 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8E71A06A2 for ; Tue, 25 Feb 2014 03:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXcNKmoy36WD for ; Tue, 25 Feb 2014 03:04:47 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id BA1531A0441 for ; Tue, 25 Feb 2014 03:04:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 914738714A0; Tue, 25 Feb 2014 12:04:45 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuYmSNZ0fF-k; Tue, 25 Feb 2014 12:04:45 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 592E5870F7F; Tue, 25 Feb 2014 12:04:45 +0100 (CET) Message-ID: <530C78CA.1000608@globis.net> Date: Tue, 25 Feb 2014 12:04:42 +0100 From: Ray Hunter User-Agent: Postbox 3.0.9 (Macintosh/20140129) MIME-Version: 1.0 To: Erik Nordmark Subject: Re: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast References: <5305AF13.5060201@acm.org> <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org> <530BCF83.4090500@acm.org> In-Reply-To: <530BCF83.4090500@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Bm1rdNa_-AR_Lclm_RVZh3ONk0k Cc: Andrew Yourtchenko , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 11:04:48 -0000 Erik Nordmark wrote: > On 2/20/14 6:43 AM, Ole Troan wrote: >> >> >>> 4.8 seems to conflate the address assignment with DAD. Just because >>> we might want to centralize the DAD checks doesn't imply that we >>> want to remove the ability for the host to pick its own privacy >>> enhanced interface-IDs to form its addresses. How would you do DAD for link-local addresses if the link is NBMA, and there's no multicast? Don't you get into a chicken/egg problem with DHCPv6? [Section 16 of RFC3315 has a MUST for using a valid source address, either link-local -> multicast or an assigned address -> unicast] >>> From a deployment perspective DHCPv6 is available for address >>> assignment, but don't think we want to require that for WiFi or >>> other links which have packet loss. (Packet loss occurs on wired >>> networks as well, but the drop distribution is different - might >>> happen during spanning tree reconvergence etc.) Why not? DHCPv6 has retransmission (controlled by the client) Why would ND registration be any different from the perspective of packet loss? >>> Note that DHCPv6 (RFC 3315) has a SHOULD for doing DAD on the >>> addresses received from the DHCP server - needed since the server >>> could be confused. >> I'd like to explore the difference between DHCP address assignment >> and ND address registration a little more. >> the state that is required in the network for "efficient ND", why >> cannot that be created and maintained by DHCP? >> I think that's a very good question. >> there are multiple ways of dealing with DAD in this scenario, >> including solutions that don't require host changes. >> DHCP also supports temporary addresses btw. > DHCP supports RFC 4941 temporary addresses, but it doesn't support > others like CGA and stable-privacy-addresses. With IA_TA the DHCP > server creates the temporary address, and that approach doesn't work > with other addresses that need to be client-generated for security or > privacy reasons. DHCPv6 [3315] itself says very little about temporary addresses. I don't see why DHCPv6 couldn't be made to support draft-ietf-6man-stable-privacy-addresses etc., although it may undermine their raison d'etre if there isn't a trust relationship with the DHCPv6 server. But then again you probably wouldn't trust DHCPv6 at all in that case. > > One could envision changing DHCP to have a separate "please register > this address" message and/or option, which would check against > duplicates (of assigned and registered addresses) and then add it to > the registered addresses in the server. But that would seem like a > fair bit of new functionality in DHCP. > Why would new messages be required? After discovering a unicast DHCPv6 server, wouldn't it be possible for a client to send a DHCPv6 request message containing an IA Address option in an IA-TA option? Where the IA Address option contains the temporary IPv6 address requested to be registered? If I read RFC3315 18.2.1 that's standard behaviour isn't it? > Currently RFC 3315 separates address assignment and DAD - the client > SHOULD perform DAD on an address that is assigned by the DHCP server. > This separation goes back to DHCPv4 where there was a similar check (I > think using ICMP echo) which I believe is there for the reason that > the DHCP servers list of assigned addresses could get out of sync with > the hosts. (If DAD fails the host declines the address hence will get > a different one.) > Correct. There may be multiple DHCPv6 servers configured via relays, so you can also get into race conditions. > I don't see how we can do this without host changes even for the case > of IA_NA and IA_TA DHCP assigned addresses; the hosts would need to > remove the code which does the DAD check for DHCP. (And there would be > additional DHCP protocol changes needed to support CGA and > stable-privacy-addresses and any future address assignment scheme.) > > Erik > > -- Regards, RayH From nobody Tue Feb 25 03:15:59 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55A71A0440 for ; Tue, 25 Feb 2014 03:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNc3LYcB5Zm2 for ; Tue, 25 Feb 2014 03:15:56 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3470B1A0316 for ; Tue, 25 Feb 2014 03:15:56 -0800 (PST) Received: from [192.168.10.18] ([78.204.24.4]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s1PBAldi029082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Feb 2014 03:10:49 -0800 Message-ID: <530C7A37.2030706@acm.org> Date: Tue, 25 Feb 2014 03:10:47 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Mark ZZZ Smith , Ole Troan Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast References: <5305AF13.5060201@acm.org> <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org> <530BCF83.4090500@acm.org> <1393319543.97599.YahooMailNeo@web162201.mail.bf1.yahoo.com> In-Reply-To: <1393319543.97599.YahooMailNeo@web162201.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;St6Ueg2e4xGTy+gyCY+HFQ== M;lL0zew2e4xGTy+gyCY+HFQ== Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/jwTHgMsOqBPdHOsVn7obZqROX9A Cc: Andrew Yourtchenko , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 11:15:57 -0000 On 2/25/14 1:12 AM, Mark ZZZ Smith wrote: > > I don't see how we can do this without host changes even for the case of > IA_NA and IA_TA DHCP assigned addresses; the hosts would need to remove > the code which does the DAD check for DHCP. (And there would be > additional DHCP protocol changes needed to support CGA and > stable-privacy-addresses and any future address assignment scheme.) > I think a DAD Proxy is what you're looking for - > > RFC6957 - "Duplicate Address Detection Proxy." Mark, RFC 6957 is useful for some types of deployment. But it don't see how it relates to my observation (in response to Ole) that DHCPv6 doesn't help with different forms of address assignment and DAD. Even with DAD proxy, or some other form of DAD enhancement, we'd still do address assignment (SLAAC, DHCPv6, stable-private, etc) separately from DAD. > > More broadly though, I think a method that supports any forms of multicast from a host to the other hosts on the link, hair-pinned through the upstream router(s), would be better. It would support DAD operation, and would also support other multicasts from hosts, such as Multicast DNS for device (printer) discovery, and SSDP for DLNA server discovery. You mean instead of hair-pinning at L2 (through the AP) do the hair-pinning at L3 (through the router)? Would the router decrement ttl as it forwards those packets? (If not, then I think you are talking about hair-pinning at L2 but placing it in the router.) Note that L2 hair-pinning typically (always?) does split horizon, hence you'd need to it in the devices along the path from the sender to the router (e.g., the AP) if you want to ensure that all receivers can get a copy of the packet. Hair-pinning can potentially be avoided for L3 - if the router decrements ttl then it would be safer to send the multicast packet out the input port. However, ttl decrements break the protocols that use the ttl=255 check (and ND isn't the only protocol which does this.) Regards, Erik > I've been thinking about this scenario for quite a while, and it seems to me that there are fundamentally two approaches to this problem. > > The first one involves minimal or no changes to the hosts (e.g., an optional RA PIO for link-local flagged as off-link and that is it, as a host local optimisation instead of ND proxy for link-local addresses), and emulate functions at the upstream router(s) that won't work because of host to host isolation within the link. > > The other one involves wholesale changes to the hosts, and I think that would mean fully implementing an IPv6 NBMA subnet, perhaps with an RA option to announce to the hosts that the link is operating in NBMA mode, and the address(es) of the MARS cluster. > > The NBMA method would be convenient, as all these sorts of multicast/link-local etc. issues are already dealt with. However, I think wholesale changes to hosts to support it are probably infeasible. > > > Regards, > Mark. > > > > >> Erik >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> From nobody Tue Feb 25 03:59:49 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D251A06B4 for ; Tue, 25 Feb 2014 03:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVIIWXOLTKYv for ; Tue, 25 Feb 2014 03:59:44 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 57E171A0447 for ; Tue, 25 Feb 2014 03:59:44 -0800 (PST) Received: from [192.168.10.18] ([78.204.24.4]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s1PBxYOA015729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Feb 2014 03:59:36 -0800 Message-ID: <530C85A6.5080404@acm.org> Date: Tue, 25 Feb 2014 03:59:34 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Andrew Yourtchenko Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast References: <5305AF13.5060201@acm.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;bAQRSxSe4xGWMOgyCY+HFQ== M;Zi6wSxSe4xGWMOgyCY+HFQ== Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/CFxfAoSWbktKwHYgSmIRqNVxcWE Cc: IETF IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 11:59:47 -0000 On 2/20/14 8:56 AM, Andrew Yourtchenko wrote: > > Yeah, it's a very useful optimization to consider, we discussed it I > think alread. The reason I did not include it yet, was to go over the > tradeoffs without the pressure of the submission deadline being a few > hours away :) > > 1) from the efficiency standpoint this approach is fantastic for the > wired and for the wireless (the implementations that do the > mcast->ucast conversion over the air the win is a bit less, but > nonetheless there is a win since we send only one packet on the wired > side instead of many and save the CPU on the gateway). > > 2) This adds an instantaneous behavior change into the network at the > peak load conditions - so if that code path has a problem, this > creates hard-to-debug situation. > > 3) There are a few trickier scenarios with L3 roaming (hosts arriving > from other subnets onto the same AP) and that AP having a single > 802.11 group encryption key, which this behavior might make easier to > accidentally have broken. I don't quite understand concern #3 (and #2). Since the routers doesn't know whether hosts rely on unsolicited multicast RAs, the multicast RAs must function. Thus adding the flash crowd optimization to multicast solicited RAs wouldn't be anything new or different - it would merely appear in one additional case. >> >> In section 4.3 there are two suggestions: MLD snooping and L2 unicast >> or L3 multicast packets. I think there are some operational concerns >> around MLD snooping - I hope others can fill in some information in >> that space since I don't know the issues. >> (Editorially it would be clearer if those two are separate >> sub-sections.) >> >> The multicast-over-unicast refers to SAVI as a way to collect the >> state, but it doesn't specify where you see that state used. >> Presumably for DAD (and NS in general unless you also do section >> 4.7)? But SAVI doesn't claim to have all addresses since it is >> concerned with conflicts. Thus a host can exist and be silent - but >> DAD would still expect to reach it. Or a host could have moved to a >> different port and SAVI having stale state - yet DAD should work. My >> point is that the details of how the state is 1) maintained and 2) >> used to forward packets are key to analyzing how the neighbor >> discovery functionality and robustness would be affected by this idea. > > The hosts that are "quiet" are indeed a problem. However, I think it > might be very OS-specific - the today's smartphones are anything but > quiet :-) > So I think this will be much more of an issue for some special-purpose > devices, which are also predominantly servers. I guess my first question was how this would work when there is no SAVI-like state for an address. (In that case you don't have a unicast address to which you can send the packet.) Would you multicast or drop? > I think the smart-meter type of device would be in this category. But > to access those, the remote party will need to know their address... > so, if a device does some sort of service registration upon boot-up, > then it will not be a quiet device anymore. But the service registration could have happened when the device was first installed - I don't think that is likely to happen each time the device wakes up. > I haven't seen this failure in the "consumer portable devices" > networks that I ran - so this is purely a mental construct. Yes, but IPv6 needs to work for other sleepy devices. We want whatever improvements we do to the standards in this space to be useful for the next 20 years or so. (Products, whether end devices or routers/switches can operate on shorter time scales and with more limited applicability than the core standards.) > > I do agree that there are limitations - but I think it is very > important to collect the data about the scope of these limitations, to > keep a balanced approach. > > The data I have as of today based on 5-6 networks with 10-20K hosts > says it is quite minimal. But I reserve the right to be wrong and thus > would be very interested to hear about other live networks where it is > different. > > (side note: if these sleepy hosts are quiet and are concerned that > their address be known, they might consider to use DHCPv6 as well). Using DHCPv6 doesn't reduce multicast (neither for address resolution nor for dad). One could change DHCP to record the link-layer addresses so that the routers would ask the DHCP servers for the link-layer addresses, but that seems like a lot of change. Also, see my response to Ole on the other ways that the DHCPv6 we currently have doesn't help solve the problems at hand. [I see others brought up the same concerns around DHCPv6 on the list.] > >> >> I section 4.4 the document refers to proxy but without specifying >> which of the different proxy approaches you have in mind. >> There is the proxy ND RFC, and there is the DAD proxy internet-draft >> in 6man. Are you referring to one of those, or some slightly >> different form of proxy? (For example, ND proxy would respond with >> the LLA of the router/AP, but that might result in host movement >> looking like a duplicate address - again depends on the details.) > > I don't know the spec. I saw it implemented in a product, where two > attached clients A and B during the ND saw the packet sequences that > were close enough to the ND spec to achieve identical practical result > and be compliant to the letter of it, yet allowed to perform the > process more optimally from the broader perspective. > > Arguably this kind of behavior would not require its own spec ? Yes, because it depending on the details it might break SeND and other ND options, or it might only be robust and useful in very limited applicability for instance in specific topologies (such as a single wireless controller). >> I don't have any issue with removing the somewhat arbitrary 9000 >> second max AdvDefaultLifetime in section 5.1. However, the tradeoff >> for what default lifetime to use in section 4.5 needs to take into >> account one additional factor. >> The default lifetime serves to garbage collect entries from the >> default router list should a router silently disappear. Thus for >> links that do not have a fixed (set of) link-local address(es) for >> the router(s), having a high default lifetime means that after a >> failure the hosts would have one entry in the default router list >> which us unreachable - until that high lifetime expires. I don't know >> if there has been a study on the performance impact of that would >> have on the hosts e.g., how often they would re-probe the default >> router. > > This is indeed a useful consideration that is worth noting in a doc > that would be removing the 9000 seconds max limit. Mind if sketch a > -00 on this matter and send you the possible text ? That would be excellent. >> Section 4.6 has the same concern. But 4.5 and 4.6 makes lots of >> sense e.g., in a VRRP deployment where the link-local address of the >> virtual default router would always be the same. Ditto for networks >> with a single point of failure single router at a fixed address >> (e.g., if the router is always at fe80::1 or some other fixed >> address.) Thus I think we should recommend 4.5 and 4.6 that within >> that applicability. Added benefit is that the routers control it, >> hence the operator of the network can set the values higher for VRRP >> or single router cases. > > I totally agree! We probably might have a series of documents for > different types of use cases - this could be very helpful for the > folks deploying them. We could turn this doc into a "large-scale > high-density WiFi (stadiums, exhibitions, campuses, etc.)" and then > have couple of others describing other types of deployments. Let's > discuss this in London ? Yep. >> In think it would be good to separate out the second half of section >> 4.7 (blocking link-locals) into a separate section, since it is quite >> different than clearing the on-link bit. That idea has significant >> implications since it changes the IP subnet model (RFC 4903 talks >> about this.) I not saying that we shouldn't consider this, but I do >> think it would fall in a very different category than the other ideas >> in this draft. Might even be best to have a separate draft on this >> radical idea so it can be explored fully. > > I thought RFC5942 was clarifying this (by the way I need to reference > it). 5942 re-states the intent of 4861 with more detail. But doesn't change the above semantics. (It does remove these two bullets from on-link: * a Neighbor Advertisement (NA) message is received for the (target) address, or * any Neighbor Discovery message is received from the address. ) The only case I know of where "blocking link-locals" is part of our standards is for multi-link subnets, for instance in 6lowpan. But in that case it was part of the architecture from the start. The issue we have with the general ND evolution is that we need to support the existing assumptions, and many of those assumptions come from IPv4. For instance, the use and semantics of an IPv4 link-local multicast has been carried to IPv6 link-locals. Removing that will cause some breakage. > > My thought process was as follows: suppose we have 9000 people, each > with a smartphone, wandering inside a large building or on campus. We > want to limit the broadcast domains. So we will split these 9000 hosts > into 256 > subnets, each with 35-36 hosts. Those are small enough to be close to > what is a typical "small network" so everything will be fine, and the > protocols which do use link-local addresses will actually be able to > function. > > Good ? Seems so, but, there are problems with this approach: > > 1) "Lobby ambassador" problem: everyone arrives through the same > entrance, and turns on their portable device there. Therefore, the > assignment of a host to the subnet must happen there, not based on > physical location, but on some loadbalancing algorithm. I have 256 > subnets, so e.g. for predictability we can use a first byte of a hash > of the host's mac address. > > 2) I need to span those 256 vlans across the entire venue, and ensure > I place each of the hosts into the correct VLAN on each AP. A typical > network of such a scale will have about 300 APs. I still need to send > RAs within each vlan. I need to ensure that the hosts do not receive > the "wrong" RAs. (and remember, there is not really a way in a naive > 802.11 imlementation to do "selective" multicast). > > 3) I have people that are able to see each other using multicast > advertisements, but what relation do they have to each other ? > Equality of the first byte of the hash of their mac address. Not very > useful. > > So I conclude, that while splitting the whole crowd into smaller > subnets somewhat takes care of the floods at the expense of additional > complexity, the resulting "working" link-local multicast protocols do > not really make any sense - because the partition of the network does > not have any other logic than pure loadbalancing. I agree with all that. For those types of deployments having /127 subnets (plus DHCPv6 PD if someone wants a personal area network behind their phone) makes a lot of sense. But my issue is that the goals we are trying to achieve are more general than the stadium (or broadband subscriber) use case. > Of course, I need to disclaim: doing this in the home network with one > AP and < 100 devices all belonging to a single person is not useful at > all. > > Doing this in a network with 9000 devices belonging to different > people is the thing that made the most sense. Agreed. > > Now that we've cut off all the services, we need to figure out how to > bring them back... And I think the further mental construct here that > would be useful is to consider this as a giant homenet with a lot of > guests. Thus, I think from the services discovery standpoint, the > products of the DNS-SD workgroup will be very beneficial here. I don't think such an approach (first break it, then get folks to fix whatever broke whether that means fixing an IETF standard, some common implementation, or various to us unknown and proprietary approaches makes sense for a retrofit. Only makes sense for a greenfield deployment where there are no assumptions that existing protocols and code continue to work. > >> >> 4.8 seems to conflate the address assignment with DAD. Just because >> we might want to centralize the DAD checks doesn't imply that we want >> to remove the ability for the host to pick its own privacy enhanced >> interface-IDs to form its addresses. >> From a deployment perspective DHCPv6 is available for address >> assignment, but don't think we want to require that for WiFi or other >> links which have packet loss. > > This is more of a fallback scenario for those who want a 100% > guarantee of address uniqueness in the network - using the existing > mechanism. But RFC 3315 doesn't guarantee uniqueness, which is why the host needs to do perform DAD in addition. > > Also as a trigger for another small discussion: > > I think it's worth modeling the real-world experience in the networks > with varying packet loss to see at which point it stops being usable, > and go from there. > > The classic IETF "Built-in hotel WiFi" topic: is it worth being > extra-sure that DAD works in that scenario ? Or is it worth fixing the > connectivity by bringing the loss down to acceptable level ? At how > many retransmits do we declare a failure ? Could we then explore a > similar approach to make the DAD more robust instead - keeping in mind > the probability of failure should be quite low ? > > This will be a good robustness improvement for the hosts that will > immediately benefit them. If we want a DAD probe mechanism that is more robust to failure then I think we should just reuse the techniques in ACD (RFC 5227) which performs ongoing conflict detection. However, that results in or broadcast/multicast messages! If we want both less multicast packets *and* a more robust DAD (including efficiently handling DAD for sleeping nodes), then I don't see any approach other than making some devices on the link be able to speak more authoritatively about the addresses present on the link. Those devices can try to build that state implicitly (gleaning from packets on the link), or explicitly. (I'll try to capture the differences between those before next week.) > >> In don't understand 4.9. Should I read it as a host shutting things >> down if it goes to sleep even for a short time, and then waking up >> and multicasting a > > depends on the definition of "short". Some hosts nap during the 100ms > interval between the 802.11 beacons. Obviously would not work here. > Maybe not do it within 5 seconds of turning the screen off. > But I certainly know my gadgets stop being reachable if I do not touch > them for a day" The loss of reachability is expected. But there is also a question about the efficiency when the device wakes up. Whether it needs to start from scratch (multicast RS, do DAD multicasts and wait for a second), or whether it can do DNA (unicast a NS to the router(s) to check it is on the same link) and avoid waiting for the lack of a response to a DAD probe. > > Sure it needs more whiteboarding. But if we assume one MAC address = > one stack (this is a fair assumption I think?), it should be possible, > here is a raw idea: Need to bring a whiteboard to London ... ;-) > > By the destination of the RS being unicast, the router knows the host > is "resolicit-capable". The source address contains the MAC address, > so it is sufficient information to create a neighbor entry with a flag > "resolicit-capable" in it. Or add a flag to the RS to say "I will re-solicit" ... > > Subsequent neighbor entries with the same MAC address will inherit the > "resolicit-capable" in it. > > (Data structure detour: don't have to index by MAC address to do this. > Take two counting bloom filters "legacy hosts' MAC addresses" and > "resolicit-capable hosts' MAC addresses". In case of a false positive > match, prefer the membership in the "legacy hosts" to avoid blackout). > > Keep the running counters of number of "resolicit-capable" ND entries > and "legacy" ND entries. I can see how you increment those counters (based on seeing a RS with a new MAC address.) But when do you decrement them? (I don't think NUD from the router can be used for this, because the host can be unreachable from the router for a few seconds due to radio issues, yet the host will still consider itself connected and not restart by sending an RS.) > > When it's time to send a periodic RA, look at the counters, and if the > count of "legacy" hosts is zero, no need to send it. > > This algorithm gives multiple deployment choices: > > 1) "legacy" mode: > > set the RA interval at 1/4 of the router lifetime. This way none of > the hosts ever reaches the half remaining time, resolicits will never > be sent, business as usual same as today. > > 2) "resolicit-capable" mode: > > set the RA interval at 3/4 of the router lifetime. Then by this time > we will have seen the RS from all the capable nodes, so we can decide > whether > to send a multicast RA or not. Presumably the RSs can be lost. One way to handle this is by agressive retransmissions (no RA after 1 second, then resend RS). Another way is to space the "retransmissions" inside the lifetime range e.g., by having the host send a RS when 1/3 of the router lifetime has passed, next when 2/3 has passed. (Generalize to k/N for N transmissions before giving up.) > > This of course needs to be worked on in order to avoid the > synchronization issues (i.e. the host can not just blast an RS > straight at half lifetime). But they are solvable: Assuming even the > existing router lifetime limit of 2.5 hours, and RA interval of 1.5 > hours, we have a space +- 0.5 hour of jitter. > > Taking an arbitrary guess of 180000 hosts within that /64, a uniformly > distributed jitter will give ~100pps of RSs which is more than > manageable. Your suggestions made me realize the stuff I put in section 8.9 in efficient-nd-05 is more complex than it needs be. No need to worry about prefix and other lifetimes - sufficient to look at the default router lifetime and make sure (by sending RSs) that the host hears from all the routers. That's good. > > NB: this is a very first napkin sketch, so it is fairly simplistic. > But I think if we were to tinker a bit more with the timers, this can > be made to work. > > There is also a question - what happen if the router has to clean up > the legacy host ND entry due to resource constraints - this can be > taken care of by temporarily going into "legacy only" mode for a > period of a couple of RA lifetimes. The router is free to just discard the NCEs - unless we change DAD to use them in some proxy approach. Even if we change DAD that way, the router can just do the SAVI thing (send a unicast NS to the host and see if it still there) - no need to multicast RAs to clean up. However, the unicast NS cleanup (or any other cleanup driven by the router expecting the host to respond) has issues with sleeping hosts. (I just realize their might be different forms of sleep - completely off and will take up based on a timer, or being woken up by arriving (unicast) packets. I don't know if there is confusion around that and whether we need different terms to make it more clear.) > > Of course, it requires the sleepy hosts to wake up every now and then. > But with a lifted router lifetime limit, it will be every 9 hours. Assuming DAD is handled without involving the hosts. > > Probably doable, but let's take a SWAG just to sanity check: > http://www.ti.com/lit/ds/symlink/cc3000.pdf and suppose they were one > day to implement IPv6 with the similar power consumption. > > I count the 802.11g, because of more efficient spectrum usage. This > gives us maximum power consumption of 207ma, and a shutdown current of > 5ua. > > Now, assuming we couple it with something like > http://www.atmel.com/Images/Atmel-2586-AVR-8-bit-Microcontroller-ATtiny25-ATtiny45-ATtiny85_Datasheet.pdf > which has standby of 0.1ua, and 12ma of active consumption (graph at > page 173 of this pdf) > > Let's say 20 seconds should be enough to make all the necessary 802.11 > arrangements, send the data, send the solicitation, and receive > advertisement. That leaves plenty of time to do the current DAD. However, Margaret had some numbers a while back with lots more frequent wakeups, but with very short runtime. I don't know if that was captured in RFC 6574 or in Margarets slides from the workshop. In any case, one issue I remember is that for Ipv4 the runtime was a lot less than one second, but with IPv6 there was an additional 1 second to wait for DAD to complete which blew the power budget. Erik > > Now, assuming we power it off the typical NiMh 1.2V elements with > 1800mAh capacity, the continous running time off it will be > 1800*3600/220 = 29454 seconds. > > Let's assume for simplicity that we wake up every 8 hours, so this > gives 60 seconds per day. This gives us the active life span of 490 days. > > Given that even the low self-discharge batteries > (http://en.wikipedia.org/wiki/Nickel%E2%80%93metal_hydride_battery#Low_self-discharge_cells) > have retain rate of 70%-85% within a year, probably this is a > reasonable lifecycle (also for this reason I am not accounting for the > standby current, it's comparable to self-discharge). > > This is of course also a quick napkin sketch, a properly engineered > approach would take into account the 802.11 maintenance stuff - and, > also it's really the "extreme" case which does not listen to the > packets while asleep - so the lifetime would certainly vary - but I > think this shows that this is not a totally unreasonable path. > > --a > >> >> Regards, >> Erik >> >> >> > From nobody Tue Feb 25 04:23:28 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3301A044C for ; Tue, 25 Feb 2014 04:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PajjrrTGzHmw for ; Tue, 25 Feb 2014 04:23:23 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id D3DEC1A06C6 for ; Tue, 25 Feb 2014 04:23:23 -0800 (PST) Received: from [192.168.10.18] ([78.204.24.4]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s1PCMBa1024746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Feb 2014 04:22:12 -0800 Message-ID: <530C8AF2.6070001@acm.org> Date: Tue, 25 Feb 2014 04:22:10 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ray Hunter Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast References: <5305AF13.5060201@acm.org> <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org> <530BCF83.4090500@acm.org> <530C78CA.1000608@globis.net> In-Reply-To: <530C78CA.1000608@globis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;OLujcxee4xGj/OgyCY+HFQ== M;nKNldBee4xGj/OgyCY+HFQ== Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/SCdiqtnSA0N8nwXcZyI4-caIrH0 Cc: Andrew Yourtchenko , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 12:23:25 -0000 On 2/25/14 3:04 AM, Ray Hunter wrote: > > > Erik Nordmark wrote: >> On 2/20/14 6:43 AM, Ole Troan wrote: >>> >>> >>>> 4.8 seems to conflate the address assignment with DAD. Just because >>>> we might want to centralize the DAD checks doesn't imply that we >>>> want to remove the ability for the host to pick its own privacy >>>> enhanced interface-IDs to form its addresses. > > How would you do DAD for link-local addresses if the link is NBMA, and > there's no multicast? ' You can't. (I'm not the one advocating turning an Ethernet into an NBMA network.) But we do have an open issue if we want to make link-local addresses efficient, since 4861 assumes that they are always on-link hence multicasting NSs etc. > > Don't you get into a chicken/egg problem with DHCPv6? [Section 16 of > RFC3315 has a MUST for using a valid source address, either link-local > -> multicast or an assigned address -> unicast] [I'm not the one saying that DHCPv6 would help her - in fact I think it is a distraction to conflate address assignment with DAD.] DHCPv6 assumes that a link-local address can be formed and used (hence do DAD on the link-local) before the first DHCPv6 packet can be sent. Yet another reason why DHCPv6 doesn't help to reduce the impact of DAD. > >>>> From a deployment perspective DHCPv6 is available for address >>>> assignment, but don't think we want to require that for WiFi or >>>> other links which have packet loss. (Packet loss occurs on wired >>>> networks as well, but the drop distribution is different - might >>>> happen during spanning tree reconvergence etc.) > > Why not? DHCPv6 has retransmission (controlled by the client) > Why would ND registration be any different from the perspective of > packet loss? I think there is some context missing. DHCPv6 can not be used for CGA, stable-privacy, or any other addresses that a host can form. For that reason I don't think we should say that if you want better reliability you should use DHCPv6 (and loose the ability to use those forms of addresses.) [But see below.] ARO is retransmitted as specified in efficient-nd-05. > DHCPv6 [3315] itself says very little about temporary addresses. I > don't see why DHCPv6 couldn't be made to support > draft-ietf-6man-stable-privacy-addresses etc., although it may > undermine their raison d'etre if there isn't a trust relationship with > the DHCPv6 server. But then again you probably wouldn't trust DHCPv6 > at all in that case. RFC 3315 has explicit support for 6574 - the address is formed on the dhcpv6 server. That approach implies that any other address assignment scheme such a stable-privacy needs to be done on the server. Implies giving the key to the server etc. Removes their raison d'etre AFAICT. One could of course define new DHCP options and behaviors to take a different approach to support stable-privacy, but that would be a fair bit of DHCP changes. But you raise questions about RFC 3315 vs. DHCPv6 server behavior when addresses are included in the IA_TA option. I can't see anything about this in 3315. Makes sense to double-check. > >> >> One could envision changing DHCP to have a separate "please register >> this address" message and/or option, which would check against >> duplicates (of assigned and registered addresses) and then add it to >> the registered addresses in the server. But that would seem like a >> fair bit of new functionality in DHCP. >> > Why would new messages be required? > > After discovering a unicast DHCPv6 server, wouldn't it be possible for > a client to send a DHCPv6 request message containing an IA Address > option in an IA-TA option? > Where the IA Address option contains the temporary IPv6 address > requested to be registered? If I read RFC3315 18.2.1 that's standard > behaviour isn't it? I don't see a sentence in 18.2.1 which says that the address in an IA is registered (after checked that it hasn't been assigned to anybody else). The number of IAs (IA_NA and IA_TA) are used to determine how many address to assign to the host. Section 12 says "Clients ask for temporary addresses and servers assign them." Nothing about checking whether they are already assigned to somebody else in that section. Ditto in section 22.5 - "The server will generate new temporary addresses and return them to the client." (But I haven't checked DHCPv6 server implementations.) Erik From nobody Tue Feb 25 05:22:08 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4457A1A06E5 for ; Tue, 25 Feb 2014 05:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dj71905Rgqwx for ; Tue, 25 Feb 2014 05:22:06 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3465E1A06E4 for ; Tue, 25 Feb 2014 05:22:06 -0800 (PST) Received: from [192.168.10.18] ([78.204.24.4]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s1PDLwpJ011290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Feb 2014 05:21:59 -0800 Message-ID: <530C98F6.6030305@acm.org> Date: Tue, 25 Feb 2014 05:21:58 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Hemant Singh (shemant)" , IETF IPv6 , Lorenzo Colitti , "Andrew Yourtchenko (ayourtch)" Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast References: <5305AF13.5060201@acm.org> <75B6FA9F576969419E42BECB86CB1B89115F99A9@xmb-rcd-x06.cisco.com> In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89115F99A9@xmb-rcd-x06.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;/GvMzR+e4xGfmegyCY+HFQ== M;WDBvzh+e4xGfmegyCY+HFQ== Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/RWJuvTHL8E693XkRB7sx_5eVxe0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 13:22:07 -0000 On 2/21/14 6:03 AM, Hemant Singh (shemant) wrote: > ErikN has commented on section 4.7. I have additional comments. ND as defined in RFC 4861 has no means to specify a prefix as off-link. Thus the L-bit equals zero is not a valid means to signal an off-link prefix to SLAAC hosts. It is correct that L=0 doesn't mean anything. For instance, if a prefix P1 has been advertised in a PIO with L=1 and later the host receives a PIO with P1 and L=0, that doesn't change anything. (But section 6.2.7 in RFC 4861 would flag it if routers advertise the same prefix that way - Oops - 6.2.7 doesn't explicitly list the PIO flags which I think is an omission.) However, ND does indicate that prefixes are off link. That is done by never advertising them, or only advertising them with L=0. That can be overridden by having individual IPv6 addresses be considered on-link through a redirection where target==destination. > The only means in ND to specify all destinations as off-link is to have the RA include no PIO and have the A-bit cleared. The hosts use DHCPv6 for address assignment. This is the NBMA ND link model. The router also supports a DAD Proxy. That isn't correct. PIO with L=0 works. SLAAC can be used even if L=0 - the case when L=0 and A=1. Regards, Erik From nobody Tue Feb 25 05:39:23 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B648D1A0657 for ; Tue, 25 Feb 2014 05:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KflSV8Srte2z for ; Tue, 25 Feb 2014 05:39:20 -0800 (PST) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id BFFC51A0457 for ; Tue, 25 Feb 2014 05:39:20 -0800 (PST) Received: from [192.168.10.18] ([78.204.24.4]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s1PDd9Hr001241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Feb 2014 05:39:11 -0800 Message-ID: <530C9CFD.2000409@acm.org> Date: Tue, 25 Feb 2014 05:39:09 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Andrew Yourtchenko , "Hemant Singh (shemant)" Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast References: <5305AF13.5060201@acm.org> <75B6FA9F576969419E42BECB86CB1B89115F99A9@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89115F9BAE@xmb-rcd-x06.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;MMObNCKe4xGU6X+iOBdzQA== M;xEVINSKe4xGU6X+iOBdzQA== Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/x-s5nMq7lmtVarSWC1VZVy95lDo Cc: IETF IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 13:39:22 -0000 On 2/21/14 12:36 PM, Andrew Yourtchenko wrote: > > Myself I did not like this portion of my reply with no quantifiable > data (because operating on a basis of a belief is not a good > engineering). > > I happened to have a couple of hours of offline time, during which I > tried to sketch the scenario and try to get as far as I can without > building a lab. > > It's a *very rough sketch*. If you think there can be parts that can > be made better in it, tell me. Andrew, I like this sketch. A few comments below. > > The initial assumptions for this thought experiment are as follows: > > 1) We have 10000 clients in a single /64. > > 2) There are multiple APs that bridge the traffic from wired onto > wireless medium, with the client count limited to 100 per AP. > > 3) there is 20x speed difference between unicast transmission and > multicast transmission.: the effective multicast speed is assumed to be > 1 mbps, the effective unicast speed is assumed to be 20mbps data rate. > > 4) The APs are assumed to be "Naive" i.e. they do not perform any > snooping > nor multicast->unicast conversions, but at the same time they are able > to bridge the unicast traffic without flooding it between multiple > access points. I.e. we assume a model where we have a single router > (or an FHRP pair) and a set of 100 APs bridging the traffic. > > (Corollary from the above: The effective unicast capacity is > 100*20mbps, whereas the effective multicast capacity is 1*1Mbps, > therefore the difference in throughput is 1000-fold). > > Let's first consider the steady state. Suppose each host downloads > a file at 0.1 mbps. Within each AP, therefore we have a 50% capacity > utilization (0.1*100 = 10Mbps, we have 20 Mbps capacity). > > It's easy to see this comfortably accomodates all the hosts. Obviuously > the unicast NUD in this traffic is fairly minimal, so I don't think > it's even worth to count how much it is. > > Now, lets look at a potential failure. > > At the time of the NUD probe, it's enough to lose the 3 retries, > spaced 1 second apart. The default reachable time is 30 seconds, > with the random jitter of 0.5 of that. > > So, all that is needed to achieve a mass NUD failure is a ~30 second > outage during the period when all the hosts are sending the traffic. > > A reboot of the majority of the networking gear takes several times > longer than this. > > Therefore, a crash of the default gateway during the peak hour is > a one guaranteed trigger for this to happen. > > So, now we have a situation of 10000 hosts which have deleted their > default gateway from the neighbor table, and send the multicast > neighbor solicitations for it. > > Assume the NS is 64 bytes, 10000 hosts sending such a packet means 64 > bytes * 8 bit * 10000 hosts = 5120000 bits/sec - or, 5 mbps. Just to make it clear, each NS retransmissions is 5 Mbits and the retransmission time is 1 second. Hence with 4861 we get 5 mbps for 3 seconds. However, they hosts aren't that likely to all discover the NUD failure in the same 3 second window. With ReachableTime=30 seconds it depends on when there last successful NUD probe or higher-level reachability advise can in. Hmm - with TCP the reachability advise might come with every left window edge advancement i.e. they would synchronize quite closely. > > Note, that this is only the shared bandwidth downstream back to the > hosts - the airtime spent by the upstream traffic is 20x faster, so I > am gratuitously discarding it. > > Since the APs can not send the traffic at this rate, obviously, we will > need to drop some of it. Note, if the clients succeed with the ND to > the default gateway, they will start streaming data again, so the > effective multicast throughput will drop to the 0.5 mbps as soon as > the noticeable portion of clients recovers. While the multicast NS will see downstream drops, what matters for the resolution is that the router receives it and responds. Thus why wouldn't that part work? The NA from the router will be unicast so if that unicast isn't dropped due to the multicasts then it should resolve quickly. I don't know if unicast is prioritized higher than multicast or not. (We'll see downstream overload due to the multicasts, but that might just last for 1 second if the NS/NA to/from the router gets through.) > > Let's assume the best case of 20% of the clients managing to recover > within the first second. > > As we are approaching full recovery, the lesser number of clients will > be able to get their multicast NS sent because the airtime is being > taken by the payload traffic. Anyway, let's discard that and assume > that every second 20% of the clients will recover. > > This means that the recovery of the full set of the clients in this > conditions will take an *absolute* minimum of 5 seconds. > > Did I prove myself wrong ? Seems so. We can see that with some of the > relaxed assumptions I took, the hosts seem to recover. > > But, let's add to this a little bit of mDNS, and other > multicast-loving protocols, which tend to generate a fair chunk of > traffic when they detect the network was "restored". > > This can shrink the available capacity several times. Add to this that > the host does not necessarily stream at 100kbps, but might have higher > data rates, and I think we can consider the available > multicast capacity at startup to be 1/10th of what it is in theory. Yes, in general TCP will fill the pipe thus at each AP all of the downstream bandwidth will be used. But if the streaming comes via the default router (which crashed or was unreachable for a few seconds), then the stream would also slow down due to TCP, in which case there is less of a multicast overload issue. There might be cases where this TCP slowdown doesn't happen though. Erik > > This is where the things may become interesting - 1/10th of the > capacity means that it will take not 5, but 50 seconds for all the > hosts to recover. > > This means that the hosts which recovered in the very first second, > will already be sending NUD traffic while the network is still under > stress. If these packets are lost, the hosts might back into the pool > of the "orphans" who are sending the multicast, because they delete > their neighbor entry. > > There are some other things to consider: > > - I deliberately kept the scenario here with *one* ND entry. > Assuming your hosts are talking with 3-4 other hosts besides the > default gateway. This increases the load and proportionally makes the > dangerous state easier to achieve. > > - another factor that I am omitting - that such a storm of ND onto the > default gateway might cause rate-limiting of the control plane packets > on the gateway. With some of the limits being as low as 1000pps, this > might give a recovery time on the order of minutes even without the > wireless multicast being the bottleneck, yet still resulting in a lot > of multicast NS in the air still during the slow recovery. > > This is about as precise of the construct I can build. > > Is it perfect ? No, by no means. It also does assume that in the case > of the default gateway the wireless performance will be limiting > factor - I think it won't - so it's more of an appropriate scenario > for a case of a p2p communications on the network. The > default-gateway-only will be inherently much more stable, I think - > because the multicast on the wired side is fast, so the drops on the > wireless side will not matter. > > It's probably worth it to change the text into "There is potential for > the failing NUD to *contribute* to a longer recovery and possible > creation of the locked situation in the case of flash failure - but > the exact quantification of the impact in such an environment is a > topic of further study". > > And then maybe I could dump the above thought experiment into a > separate draft, to see if the folks could contribute to the experiment > / maybe someone could run it - and reference it in this item ? > > It seems like an interesting area to dig a bit more in - creating a > suitable model and playing with the parameters to see where it breaks > seems like a useful exercise to understand how many hosts can there be > in a single /64 on WiFi with a "naive" set of access-points. > > Thoughts ? > > --a > From nobody Tue Feb 25 05:58:40 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6811A0644 for ; Tue, 25 Feb 2014 05:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.065 X-Spam-Level: ** X-Spam-Status: No, score=2.065 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jus4PEOh2e2I for ; Tue, 25 Feb 2014 05:58:36 -0800 (PST) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id DC4CF1A007D for ; Tue, 25 Feb 2014 05:58:36 -0800 (PST) Received: from [192.168.10.18] ([78.204.24.4]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s1PDvRW2007913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Feb 2014 05:57:29 -0800 Message-ID: <530CA147.5050100@acm.org> Date: Tue, 25 Feb 2014 05:57:27 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ole Troan , "Eric Levy- Abegnoli (elevyabe)" Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast References: <1607A96C-5760-42B0-ADFB-325F03D83834@employees.org> In-Reply-To: <1607A96C-5760-42B0-ADFB-325F03D83834@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;Ag8BwySe4xG+YH+iOBdzQA== M;yhauwySe4xG+YH+iOBdzQA== Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/1_wixv3B_T0Q0QX-GljGd_Ezqlc Cc: Andrew Yourtchenko , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 13:58:38 -0000 On 2/22/14 4:02 AM, Ole Troan wrote: > Yes we do. They are about half the problem, an't they? More if most > traffic is local to the link. Less otherwise. > I think that's an important point for the problem definition. Ole, It is at least a question we should ask in the problem definition. > I do agree with you that if we need to register link-local addresses too, and change the model of link-local addresses always being on-link, then we might look for other solutions. that's not what efficient ND seems to do though. as far as I can see the ND efficient draft suggests ND for link-local traffic is done like today. See section 18 "Open Issues". (6lowpan-nd has a limited-applicability approach to handle link-local addresses which we can't use in general.) > > I did a couple of packet captures on my relatively fruity home network. I did not see a single data packet using link-local addresses. I saw ND and I saw lots of mDNS (someone needs to solve that problem too). > I don't claim my home network is representative, but I'd really like to see more data here. > I presume we're not going to justify this work based on the 10000 node dentist's office (1)? > > any application depending on link-locals would also break in the routed home case. It wouldn't necessarily break - it all depends on the semantics that folks expect. For instance, in 6lowpan a link-local which matches the radio topology makes a lot of sense - is useful for routing and other adjacency protocols (such as trickle distribution). A (large) home could be intentionally set up so that the subnet in the north wing gives you the mDNS etc resources for the north wing. But a more likely case is that the routing happens between different network topologies (Ethernet, IEEE 802.15.4, etc) where there is no particular user intent to have different resource discovery scopes tied to the different links. > and if we really wanted to solve it, what's the solution space? > - redefine link-locals to have an L-flag? > - physically or virtually restricting the link-local subnet size? > - disable link-locals? I don't think we can remove link-local from the whole link. For instance, the routers might use VRRP and VRRP uses IPv6 link-locals (with a ttl=255 check.) And in some topologies the routers might have OSPFv3 or other adjacencies over the link, and the routing protocols use IPv6 link-locals. At best we could have the hosts not send packets using link-locals for applications. Telling the host to send link-local packets to the routers wouldn't help with protocols with do the ttl=255 check, and I don't know if this applies to mDNS or other protocols which use link-locals. However, it would seem to be useful to avoid the hosts trying to send such link-locals, since they would just use resources for no real use. Thus a "send link-locals to router" indication in an RA seems useful if we want to solve this. That enables some compatibility for hosts (which interpret that flag but do not change their application protocols) since the router could proxy mDNS etc (handwaving a bit). Erik From nobody Tue Feb 25 06:10:43 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64201A0720 for ; Tue, 25 Feb 2014 06:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKmv7k0uwKP9 for ; Tue, 25 Feb 2014 06:10:40 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id CD07A1A06DA for ; Tue, 25 Feb 2014 06:10:40 -0800 (PST) Received: from [192.168.10.18] ([78.204.24.4]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s1PEAW75029155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Feb 2014 06:10:33 -0800 Message-ID: <530CA457.1000400@acm.org> Date: Tue, 25 Feb 2014 06:10:31 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Mark ZZZ Smith , Ole Troan , "Eric Levy- Abegnoli (elevyabe)" Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast References: <1607A96C-5760-42B0-ADFB-325F03D83834@employees.org> <1393114084.46822.YahooMailNeo@web162205.mail.bf1.yahoo.com> In-Reply-To: <1393114084.46822.YahooMailNeo@web162205.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;sLCBliae4xGzYugyCY+HFQ== M;Dosglyae4xGzYugyCY+HFQ== Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/4qerw-TYUnM3DWvj9OIKJlka5ic Cc: Andrew Yourtchenko , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 14:10:42 -0000 On 2/22/14 4:08 PM, Mark ZZZ Smith wrote: > > > > ----- Original Message ----- >> From: Ole Troan >> To: Eric Levy- Abegnoli (elevyabe) >> Cc: Erik Nordmark ; Andrew Yourtchenko ; 6man WG >> Sent: Saturday, 22 February 2014 11:02 PM >> Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast >> >> Eric, >> >>>> do we need to care about link-locals? are they part of the problem we >>>> need to solve? >>> Yes we do. They are about half the problem, an't they? More if most >>> traffic is local to the link. Less otherwise. >> I think that's an important point for the problem definition. >> I do agree with you that if we need to register link-local addresses too, and >> change the model of link-local addresses always being on-link, then we might >> look for other solutions. that's not what efficient ND seems to do though. >> as far as I can see the ND efficient draft suggests ND for link-local traffic is >> done like today. >> >> I did a couple of packet captures on my relatively fruity home network. I did >> not see a single data packet using link-local addresses. I saw ND and I saw lots >> of mDNS (someone needs to solve that problem too). >> I don't claim my home network is representative, but I'd really like to >> see more data here. >> I presume we're not going to justify this work based on the 10000 node >> dentist's office (1)? >> >> any application depending on link-locals would also break in the routed home >> case. >> >> and if we really wanted to solve it, what's the solution space? >> - redefine link-locals to have an L-flag? >> - physically or virtually restricting the link-local subnet size? >> - disable link-locals? >> > So I've been thinking about this problem off-and-on for a few months (specifically this, and more generally using hub-and-spoke link-layer forwarding in a multiaccess subnet, as I think it is a more general solution to the various RA/DHCPv6 spoofing etc problems, and also is more energy efficient), and I've started writing up a draft which suggests the following solution: Mark, I understand the potential benefits of doing this for multicast. Are you also looking at requiring it for unicast? (Direct host-host unicast would seem more efficient - but in some use cases with filtering requirements it would make sense to send those via the router as well.) > > - Allow RA PIOs to announce the link-local prefix, to switch the on-link assumption for the link-local prefix off (the A bit in the PIO would be ignored for the LL prefix) > > - Routers perform a limited form of ND proxying to facilitate hosts that don't support this LL RA PIO. ND proxying only occurs for Link-Local addresses. *If* we need to solve this I think that is a reasonable design. We do need to look at ttl=255 in a bit more detail - I assume you'd decrement ttl when the routers forward link-locals back out on the link. > > The only issue I think that is left open after this link-local issue is host originated multicasts. The link-layer forwarding model would force them to only be received by the router(s) at the hub(s). The question is how do the multicasts reach the other hosts on the link? > > Simplistically, the router could just flood the multicasts back to all hosts on the link (continuing to use the link-layer's broadcast/multicast capability retained for the devices at the hub(s)). I don't know if that is legal, but assuming it is, would the multicast origin host ignore its own multicasts? It could tell they were its own because the source address would be one of its own. I've had a bit of a look into the RFCs to see if this router and host multicast behaviour is defined, but haven't been able to find it. DAD as currently defined would break, since DAD can't cope with hearing its own packets. But if we do that differently (enhanced-dad draft with nonce, or address registration) that wouldn't be an issue for hosts that implement that new approach. Still need to handle legacy hosts doing current DAD though ... need to think about that one. Once DAD is taken care of and we assume unique link-layer addresses, then having the host ignore multicast packets with its own IP source address will ensure that other protocols/applications don't see any change. > > Alternatively, the router could selectively forward the multicasts back to all hosts on the link except the one it received it from. This could be achieved using link-layer unicasts and "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast IPv6" (http://tools.ietf.org/html/draft-smith-mldv2-link-unicast-00). That would be hard to implement in existing hardware. The hardware which performs multicast replication assumes the same packet is being replicated (with some handling of ttl decrement vs. not in order to handle the bridge-route-bridge paradigm for devices that are both routers and bridges i.e. where some ports see a L2 forwarded multicast packet and other ports get the same packet after a ttl decrement by the L3 forwarding function.) Regards, Erik From nobody Tue Feb 25 06:48:05 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14A11A037A for ; Tue, 25 Feb 2014 06:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5YiLk2P2b0z for ; Tue, 25 Feb 2014 06:48:02 -0800 (PST) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id 74CED1A0309 for ; Tue, 25 Feb 2014 06:48:02 -0800 (PST) Received: from [192.168.10.18] ([78.204.24.4]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s1PEjnNQ030064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Feb 2014 06:45:51 -0800 Message-ID: <530CAC9D.1040105@acm.org> Date: Tue, 25 Feb 2014 06:45:49 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ole Troan Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast References: <5305AF13.5060201@acm.org> <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org> <530BCF83.4090500@acm.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;jOGfhCue4xGczn+iOBdzQA== M;HHVEhSue4xGczn+iOBdzQA== Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/4qapuTFf4CSkg7L5GQ_IL3rWX7s Cc: Andrew Yourtchenko , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 14:48:04 -0000 On 2/25/14 1:28 AM, Ole Troan wrote: > > RFC3315 says: > The client MAY include addresses in the IAs as a hint to the server about addresses for > which the client has a preference. > > that's not too far off from the ND register semantics. in both cases the final say of which address the host can used is moved to the network. Ole, Thanks for finding that text. So a potential approach would be to have the host form its address using the SLAAC method it prefers (such as stable-privacy) and then go through the DHCP (discovery plus request/response having the IA_NA/TA with the formed address). I don't know if we can use the 2 packet DHCP exchange for this or need the 4 packet one. The host would get lifetimes back from the DHCP server so it would know when it needs to renew. If all the hosts on the link were to do this, and the DHCP service is 100% reliable, then this would ensure no duplicates. But it has issues with incremental deployment where some hosts do this but not the legacy hosts, since the legacy hosts would do current DAD probes and not find out about the addresses registered with the DHCP server. If the DHCP server is on-link it could proxy respond (and also implicitly learn about registrations from those DAD probes - with the limitations for implicit registrations which I'm trying to write down), but what about the case of DHCP relay(s) on the link and an off-link DHCP server? In that case it seems like the DHCP relays need to relay all DAD packets to the DHCP server, so that it can respond (duplicate or ok), and build it state. And should the DHCP service loose some or all of its state (e.g., a cold standby is started after a hardware failure) then it doesn't have a way to rebuild its state from the network until the lifetimes cause the new hosts to renew. And for legacy hosts the DHCP server/relay would need to glean on data packets to reliably find out about addresses that are in use since the legacy host do not "renew" with an additional DAD probe in a predictable time. Thus it seems like in order to solve DAD using DHCPv6 we need to 1. solve how do reliably do implicit registrations from DAD (and data packets?) for legacy hosts in DHCP relay/server 2. new interaction between DHCP relay and server to handle legacy hosts in normal operation 3. ditto in the case of DHCP server state loss Note that this doesn't remove the need to multicast Neighbor Solutions for address resolutions, since the DHCP server or relay is not required to be implemented in the router (it might be in some deployments and products). Even when it implemented in the router, there would need to be a mechanism to share the state of IP->MAC address between the routers on the link. Thus to solve that we need 4. DHCP server track MAC address to get IP->MAC binding 5. Sharing of DHCP server state with all the routers on the link With the above we still haven't addressed the unsolicited multicast RAs, thus we'd also need 6. Method to avoid multicast RAs - host driven unicast RS to refresh? Note that if we solve 1, 5', and 6 we have a complete solution i.e. 1. solve how do reliably do implicit registrations from DAD (and data packets) in routers 5': sharing of that registration state (explicitly or implicitly) between the routers on the link 6. Method to avoid multicast RAs - host driven unicast RS to refresh? Thus I don't see how "reusing DHCP" makes for less work - it seems to create a lot more work by changing not only hosts and routers but also DHCP servers and DHCP relays plus defining additional need for state sharing which doesn't exist today. [And as I've indicated, I think that #1 is actually hard even if there are products that do that with constrained applicability today. More about that later since it doesn't affect the difference between "reuse DHCP" and other parts of the solution space AFAICT.] > >> Currently RFC 3315 separates address assignment and DAD - the client SHOULD perform DAD on an address that is assigned by the DHCP server. This separation goes back to DHCPv4 where there was a similar check (I think using ICMP echo) which I believe is there for the reason that the DHCP servers list of assigned addresses could get out of sync with the hosts. (If DAD fails the host declines the address hence will get a different one.) >> >> I don't see how we can do this without host changes even for the case of IA_NA and IA_TA DHCP assigned addresses; the hosts would need to remove the code which does the DAD check for DHCP. (And there would be additional DHCP protocol changes needed to support CGA and stable-privacy-addresses and any future address assignment scheme.) > are there two issues here? > 1) DAD detecting a duplicate address > 2) DAD wasting bandwidth and energy Yes, we can think about those separate. I'd call #1 something like "More robust/reliable DAD" in the presense of packet loss, sleeping hosts, etc. > > on a WIFI link, DAD is sent L2 unicast to the AP. then the AP is expected to forward that packet as L2 multicast back onto the link. if we assume some smarts on the AP, then it doesn't have to send the packet back out on the wire, but only bridge it up to router(s) for example. (this isn't as far fetched as it seems, there are deployed products doing this already). Presumably the AP would do that for a large set of packets - e.g., all solicited-node MC addresses. > > given all knowing state in the network, then collisions shouldn't happen. if the network suspected it had lost state, it could try to resolve the address on the link before assigning the address to the host. Unless the host that has the address is in deep sleep at that point in time. > > leaving the host unchanged in this scheme only leaves us with the problem of the sleeping host waking up at ever beacon with a DTIM indication. since there wouldn't be a multicast message, it wouldn't have to stay awake actually waiting for a frame. If the network lost the state about the address, how can it remember to which MAC address it can unicast it? I think it needs to multicast the frame. And the host needs to be in shallow sleep so the multicast will wake it up. (Philosophically having completely separate behavior and code to deal with infrequent events like this is a bad idea; that behavior/code will not be exercised hence it is very likely to have bugs.) > > to conclude, if my understanding is correct (which it may very well not be, since I haven't really understood how 802.11 works before now), then DAD isn't a big issue. it can be solved (and is in deployed products) on the AP multicast handling. I don't see the details of how this would work. Hence I can't declare it to be solved. > > we could of course also specify in a new IPv6 over foo document that DAD attempts = 0 on these links, or perhaps better add a signal in RAs. DAD attempts = 0 might make sense for EUI-64 derived addresses. But since we are moving away from those I'm not sure that is a good idea. Erik From nobody Tue Feb 25 07:45:58 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7DB1A07A3 for ; Tue, 25 Feb 2014 07:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.252 X-Spam-Level: X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5faixLXtj6Z for ; Tue, 25 Feb 2014 07:45:54 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id EF8DF1A005F for ; Tue, 25 Feb 2014 07:45:53 -0800 (PST) Received: from dhcp-10-61-98-104.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 5096E60C1; Tue, 25 Feb 2014 07:45:39 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_8FBB2F6B-F7D0-411A-83B7-0888A0C0F1B9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast From: Ole Troan In-Reply-To: <530CAC9D.1040105@acm.org> Date: Tue, 25 Feb 2014 16:45:33 +0100 Message-Id: <2CFB5723-A676-4ADD-B555-83752997CFD7@employees.org> References: <5305AF13.5060201@acm.org> <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org> <530BCF83.4090500@acm.org> <530CAC9D.1040105@acm.org> To: Erik Nordmark X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/hPxajqPu4LbpF9l4Ebqzwqv3Pc4 Cc: Andrew Yourtchenko , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 15:45:57 -0000 --Apple-Mail=_8FBB2F6B-F7D0-411A-83B7-0888A0C0F1B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Erik, >> RFC3315 says: >> The client MAY include addresses in the IAs as a hint to the server = about addresses for >> which the client has a preference. >>=20 >> that's not too far off from the ND register semantics. in both cases = the final say of which address the host can used is moved to the = network. >=20 > Thanks for finding that text. >=20 > So a potential approach would be to have the host form its address = using the SLAAC method it prefers (such as stable-privacy) and then go = through the DHCP (discovery plus request/response having the IA_NA/TA = with the formed address). I don't know if we can use the 2 packet DHCP = exchange for this or need the 4 packet one. The host would get = lifetimes back from the DHCP server so it would know when it needs to = renew. you could only use 2 message exchange if there was a single DHCP server = on the link. > If all the hosts on the link were to do this, and the DHCP service is = 100% reliable, then this would ensure no duplicates. > But it has issues with incremental deployment where some hosts do this = but not the legacy hosts, since the legacy hosts would do current DAD = probes and not find out about the addresses registered with the DHCP = server. If the DHCP server is on-link it could proxy respond (and also = implicitly learn about registrations from those DAD probes - with the = limitations for implicit registrations which I'm trying to write down), = but what about the case of DHCP relay(s) on the link and an off-link = DHCP server? DHCP always has an on-link presence, be it the relay or the server. in = theory (which is very far from practice), relays are stateless. for this = discussion I suggest we assume DHCP must be deployed so that there is a = DHCP server on-link and on every router. with regards to your legacy point, with DHCP we can "declare" that there = is no legacy. if you want to connect to networks like these, then DHCP = is the only option for address assignment. just like there are networks = deployed like that today. > In that case it seems like the DHCP relays need to relay all DAD = packets to the DHCP server, so that it can respond (duplicate or ok), = and build it state. any scheme we can find that has no or few legacy implications would be = good. in the above scheme with the deployment restrictions outlined, DAD = messages could be silently dropped at the AP/router. > And should the DHCP service loose some or all of its state (e.g., a = cold standby is started after a hardware failure) then it doesn't have a = way to rebuild its state from the network until the lifetimes cause the = new hosts to renew. And for legacy hosts the DHCP server/relay would = need to glean on data packets to reliably find out about addresses that = are in use since the legacy host do not "renew" with an additional DAD = probe in a predictable time. I agree that DHCP performs poorly with regards to "server initiated" = messages. after a state-loss event you could do one of (again assuming no host = changes): - DHCP bulk lease query - fall back to normal ND behaviour - low timers - learn DHCP database from neighbouring routers > Thus it seems like in order to solve DAD using DHCPv6 we need to > 1. solve how do reliably do implicit registrations from DAD (and data = packets?) for legacy hosts in DHCP relay/server > 2. new interaction between DHCP relay and server to handle legacy = hosts in normal operation > 3. ditto in the case of DHCP server state loss I don't think we should go there, and if that's where we want to go, = then I'm much more open at looking at new approaches. > Note that this doesn't remove the need to multicast Neighbor Solutions = for address resolutions, since the DHCP server or relay is not required = to be implemented in the router (it might be in some deployments and = products). Even when it implemented in the router, there would need to = be a mechanism to share the state of IP->MAC address between the routers = on the link. > Thus to solve that we need > 4. DHCP server track MAC address to get IP->MAC binding yes. so I have never heard about a case where a DHCP relay wasn't on the = forwarding path. relays or servers must in any case be on-link. I suggested above that we = simplify the scenario (and discussion) by assuming the DHCP server was = on-link and running on a router. with regards to the IP -> MAC binding. - DHCP server gleans that information from ND/DHCP packets (e.g. RS) = (ugly score of 3) - Hosts implement RFC6939 (ugly score of 2) - DHCP server uses normal address resolution to learn the L3/L2 mapping > 5. Sharing of DHCP server state with all the routers on the link yes, that's the trickiest part of this scheme. this is a challenge whatever solution you choose here. even with ND = register, where the proposal is for hosts to register with all on-link = routers, you may get into a state where the databases aren't in sync. = and also it forces hosts to quickly detect the appearance of a new = router on the link. a fallback to normal ND is the only approach I can see off hand. for any = solution we propose here. > With the above we still haven't addressed the unsolicited multicast = RAs, thus we'd also need > 6. Method to avoid multicast RAs - host driven unicast RS to refresh? yes, that's independent of this I think. but as I think Andrew outlines = in his document you can get reasonably far with that without host = changes. > Note that if we solve 1, 5', and 6 we have a complete solution i.e. > 1. solve how do reliably do implicit registrations from DAD (and data = packets) in routers > 5': sharing of that registration state (explicitly or implicitly) = between the routers on the link > 6. Method to avoid multicast RAs - host driven unicast RS to refresh? >=20 >=20 > Thus I don't see how "reusing DHCP" makes for less work - it seems to = create a lot more work by changing not only hosts and routers but also = DHCP servers and DHCP relays plus defining additional need for state = sharing which doesn't exist today. if we need to put the state in the network, then I don't see that the = maintaining network state for the L3/L2 mapping is different regardless = of how you wrap the data. > [And as I've indicated, I think that #1 is actually hard even if there = are products that do that with constrained applicability today. More = about that later since it doesn't affect the difference between "reuse = DHCP" and other parts of the solution space AFAICT.] I think DHCP is largely a deployment choice. and that unless we agree on = the assumptions, e.g. no legacy (which means we don't need 1) then I = agree with you. DHCP as a solution only makes sense within certain = constraints. again I don't see how 6 isn't orthogonal to this. ah, sorry double = negative. ;-) 4 and 5 are the biggest issues with a DHCP based solution. no host changes, but definitely router/DHCP changes, and possibly AP = changes. >>> Currently RFC 3315 separates address assignment and DAD - the client = SHOULD perform DAD on an address that is assigned by the DHCP server. = This separation goes back to DHCPv4 where there was a similar check (I = think using ICMP echo) which I believe is there for the reason that the = DHCP servers list of assigned addresses could get out of sync with the = hosts. (If DAD fails the host declines the address hence will get a = different one.) >>>=20 >>> I don't see how we can do this without host changes even for the = case of IA_NA and IA_TA DHCP assigned addresses; the hosts would need to = remove the code which does the DAD check for DHCP. (And there would be = additional DHCP protocol changes needed to support CGA and = stable-privacy-addresses and any future address assignment scheme.) >> are there two issues here? >> 1) DAD detecting a duplicate address >> 2) DAD wasting bandwidth and energy > Yes, we can think about those separate. > I'd call #1 something like "More robust/reliable DAD" in the presense = of packet loss, sleeping hosts, etc. >>=20 >> on a WIFI link, DAD is sent L2 unicast to the AP. then the AP is = expected to forward that packet as L2 multicast back onto the link. if = we assume some smarts on the AP, then it doesn't have to send the packet = back out on the wire, but only bridge it up to router(s) for example. = (this isn't as far fetched as it seems, there are deployed products = doing this already). > Presumably the AP would do that for a large set of packets - e.g., all = solicited-node MC addresses. >>=20 >> given all knowing state in the network, then collisions shouldn't = happen. if the network suspected it had lost state, it could try to = resolve the address on the link before assigning the address to the = host. > Unless the host that has the address is in deep sleep at that point in = time. >=20 >>=20 >> leaving the host unchanged in this scheme only leaves us with the = problem of the sleeping host waking up at ever beacon with a DTIM = indication. since there wouldn't be a multicast message, it wouldn't = have to stay awake actually waiting for a frame. > If the network lost the state about the address, how can it remember = to which MAC address it can unicast it? > I think it needs to multicast the frame. And the host needs to be in = shallow sleep so the multicast will wake it up. >=20 > (Philosophically having completely separate behavior and code to deal = with infrequent events like this is a bad idea; that behavior/code will = not be exercised hence it is very likely to have bugs.) agree. >> to conclude, if my understanding is correct (which it may very well = not be, since I haven't really understood how 802.11 works before now), = then DAD isn't a big issue. it can be solved (and is in deployed = products) on the AP multicast handling. > I don't see the details of how this would work. Hence I can't declare = it to be solved. >>=20 >> we could of course also specify in a new IPv6 over foo document that = DAD attempts =3D 0 on these links, or perhaps better add a signal in = RAs. > DAD attempts =3D 0 might make sense for EUI-64 derived addresses. But = since we are moving away from those I'm not sure that is a good idea. DAD was invented largely to detect manual misconfiguration. as long as the network is assigning the address instead of the host, DAD = isn't required. the assigning entity could do the duplicate detection itself, and that = it can do from its own valid source address. depending on network entities detecting a DAD message and using that to = inject state in the network is a poor choice I think. DAD is unreliable, = default DAD attempts is zero. although it is sent as L2 unicast it will = still have a typical failure rate of 1-5% on WIFI. if we want network state for link-local addresses, and duplicate address = detection, and also allow applications to use link-local addresses, then = we need to 'figure' something out. I agree that without host changes = that's tricky. while the network might detect and install state for the = link-local address on e.g. RS/DHCP SOLICIT, the host might not be = receptible to changing it after DAD has passed. lots of good points here, do you collect them for a later draft? =20 cheers, Ole --Apple-Mail=_8FBB2F6B-F7D0-411A-83B7-0888A0C0F1B9 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 iQEcBAEBCgAGBQJTDLqdAAoJEFuJXizso86gqi8IAL+KOVS9I1JN0Ad0c6fh6rKD TP8YnYzIS4yXcBd7O/lptL3XdnCoVQ8hgJImWHyLKTYoiM+sGjfL/WivrG3wRTAF DD5uw64F51chclM8gdVfE4RWzl0Fdi4rslAGb7gqqMA3XtFC/IIEkyOn9a2SNkH4 1O0L27EbReliIPZ0tSnX2DDt9wPTxuGs8K2J8GbvJW/U1WMAK0479B9nJKWebRly x80RldzfQ20LBn5H4xGOX24YcatmtXeBCcGEV+Nk5Z8cP7SNhunNJCA6MoGeHhe4 eOkIzrL2YbgS0UPs1AZw5Y/94sDCTdNl3abPLhx+99w0TGq7slVkat20bZzVHP0= =Tt/c -----END PGP SIGNATURE----- --Apple-Mail=_8FBB2F6B-F7D0-411A-83B7-0888A0C0F1B9-- From nobody Tue Feb 25 10:03:31 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED101A063A for ; Tue, 25 Feb 2014 10:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TeDKIlzbmAa for ; Tue, 25 Feb 2014 10:03:20 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 884571A0294 for ; Tue, 25 Feb 2014 10:03:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=905; q=dns/txt; s=iport; t=1393351399; x=1394560999; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XoeogA0H2/U6cfcN6xlv9o+0H1G6fApPPRkgE4rHGBQ=; b=bHHWwbyzOeLgIvKBueluWu4/wlYXsv7DnQkSvqfYrwx6aeDdGUnm2KLe wQYip0VO7sqhruFFt+nUQqb1VzQL3mx/Cwu7qCFyICa2unJsTRThWaL2w sLn0RSsAK/CQPU6WbmW3+aOzYSj2PqmYxD1tXBcCr+cz68GavB41d/Ebq g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFADDaDFOtJXHB/2dsb2JhbABZgwbCY4EYFnSCJQEBAQMBeQULAgEIDjgyJQIEDgWHfQjHVReOMTMHgySBFAEDiRCPJJIngy2Bah8 X-IronPort-AV: E=Sophos;i="4.97,541,1389744000"; d="scan'208";a="23083084" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-7.cisco.com with ESMTP; 25 Feb 2014 18:03:19 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1PI3J9M001594 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 18:03:19 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.84]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 12:03:19 -0600 From: "Pascal Thubert (pthubert)" To: Ole Troan Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Topic: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Index: AQHPLg20SjVxfDziP0SiLTMeBLFIcJrFDYrPgACPzGuAAIPBAIAAKodS Date: Tue, 25 Feb 2014 18:03:18 +0000 Message-ID: <78794A62-F936-4918-9AE2-7152A0A1864C@cisco.com> References: <5305AF13.5060201@acm.org> <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org>, <530BCF83.4090500@acm.org> , <1657A615-4C3F-4C59-9A87-05B78905F264@employees.org> In-Reply-To: <1657A615-4C3F-4C59-9A87-05B78905F264@employees.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/gk9pzlqWZR7NAP-842CVJFbk-QY Cc: Erik Nordmark , "Andrew Yourtchenko \(ayourtch\)" , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 18:03:22 -0000 Well,=20 Release is of course important, but what=B4s really missing is NUD. It is quite useful for the proxy to be able to revalidate the presence of t= he device when the lifetime is long and traffic very occasional. Our implementation has a "reachable" timer that, when elapsed, will force t= o go back to the device before answering to a lookup. Cheers, =20 Pascal > Le 25 f=E9vr. 2014 =E0 10:31, "Ole Troan" a =E9cri= t : >=20 > Pascal, >=20 >> And we need to remember that the assignment is just one component of the= lifecycle of an address.=20 >>=20 >> When the client stops using an address, or moves the address somewhere e= lse in the fabric, there is a need to update the network support that defen= ds the address and proxies. >=20 > why isn't that: SOLICIT, CONFIRM, RENEW, REBIND, RELEASE? >=20 > cheers, > Ole without hat. >=20 From nobody Tue Feb 25 13:56:23 2014 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76CAC1A0257 for ; Tue, 25 Feb 2014 13:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.189 X-Spam-Level: ** X-Spam-Status: No, score=2.189 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWePv5H1K0nM for ; Tue, 25 Feb 2014 13:56:16 -0800 (PST) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3111A01E5 for ; Tue, 25 Feb 2014 13:56:16 -0800 (PST) Received: from [192.168.10.18] ([78.204.24.4]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s1PLr65o030990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Feb 2014 13:53:07 -0800 Message-ID: <530D10C2.3080208@acm.org> Date: Tue, 25 Feb 2014 13:53:06 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ole Troan Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast References: <5305AF13.5060201@acm.org> <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org> <530BCF83.4090500@acm.org> <530CAC9D.1040105@acm.org> <2CFB5723-A676-4ADD-B555-83752997CFD7@employees.org> In-Reply-To: <2CFB5723-A676-4ADD-B555-83752997CFD7@employees.org> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Sonic-ID: C;Emp8NWee4xGJPtl8OBdzQA== M;dCIbNmee4xGJPtl8OBdzQA== Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/M0XRDUQGWlZJWmXp2sW_1iQNUcI Cc: Andrew Yourtchenko , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 21:56:18 -0000
On 2/25/14 7:45 AM, Ole Troan wrote:

So a potential approach would be to have the host form its address using the SLAAC method it prefers (such as stable-privacy) and then go through the DHCP (discovery plus request/response having the IA_NA/TA with the formed address). I don't know if we can use the 2 packet DHCP exchange for this or need the 4 packet one.  The host would get lifetimes back from the DHCP server so it would know when it needs to renew.

you could only use 2 message exchange if there was a single DHCP server on the link.
I guess the host would need to do the discover once, but then can do each address registration with just 2 messages.


If all the hosts on the link were to do this, and the DHCP service is 100% reliable, then this would ensure no duplicates.
But it has issues with incremental deployment where some hosts do this but not the legacy hosts, since the legacy hosts would do current DAD probes and not find out about the addresses registered with the DHCP server. If the DHCP server is on-link it could proxy respond (and also implicitly learn about registrations from those DAD probes - with the limitations for implicit registrations which I'm trying to write down), but what about the case of DHCP relay(s) on the link and an off-link DHCP server?

DHCP always has an on-link presence, be it the relay or the server. in theory (which is very far from practice), relays are stateless. for this discussion I suggest we assume DHCP must be deployed so that there is a DHCP server on-link and on every router.
You can't have it on every router unless there is a server-server protocol to coordinate the address assignments/registrations between the routers that are on the same link. There is no IETF standard for this (it was discussed and abandoned in the DHC WG a long time back).

with regards to your legacy point, with DHCP we can "declare" that there is no legacy. if you want to connect to networks like these, then DHCP is the only option for address assignment. just like there are networks deployed like that today.
I fear you are equating DHCPv6 as implemented by hosts today, and the extensions on the hosts necessary to use DHCP for address registrations. If you say that you will only support hosts that implement DHCP address registrations (for all addresses SLAAC - 4941, stable-privacy, microsoft privacy addresses, etc) then you will support no hosts at all on those links.

That sounds like a non starter to me.


In that case it seems like the DHCP relays need to relay all DAD packets to the DHCP server, so that it can respond (duplicate or ok), and build it state.

any scheme we can find that has no or few legacy implications would be good.
in the above scheme with the deployment restrictions outlined, DAD messages could be silently dropped at the AP/router.


And should the DHCP service loose some or all of its state (e.g., a cold standby is started after a hardware failure) then it doesn't have a way to rebuild its state from the network until the lifetimes cause the new hosts to renew. And for legacy hosts the DHCP server/relay would need to glean on data packets to reliably find out about addresses that are in use since the legacy host do not "renew" with an additional DAD probe in a predictable time.

I agree that DHCP performs poorly with regards to "server initiated" messages.
after a state-loss event you could do one of (again assuming no host changes):
 - DHCP bulk lease query
Who would respond to that? There is no relay in your picture as I understand it.
 - fall back to normal ND behaviour
When the DHCP server or router crashes it typically starts clean, hence it doesn't know whether it lost state, or is a newly installed/configured node. Thus it wouldn't be "fall back" AFAICT, but actually a requirement to always start in normal ND behavior and then somehow move towards DHCP address registrations.

You probably want to walk through all the details and write down the proposal - more efficient than me trying to guess and second guess how you think it might work and poke holes at my own guesses.

 - low timers
 - learn DHCP database from neighbouring routers


Thus it seems like in order to solve DAD using DHCPv6 we need to
1. solve how do reliably do implicit registrations from DAD (and data packets?) for legacy hosts in DHCP relay/server
2. new interaction between DHCP relay and server to handle legacy hosts in normal operation
3. ditto in the case of DHCP server state loss

I don't think we should go there, and if that's where we want to go, then I'm much more open at looking at new approaches.
I don't see how you can support legacy hosts without that. We can't assume that legacy hosts do DHCP address registrations for RFC 4941 temporary addresses when the A flag is set. Clearing the A flag means that some legacy hosts will not work on those links.



Note that this doesn't remove the need to multicast Neighbor Solutions for address resolutions, since the DHCP server or relay is not required to be implemented in the router (it might be in some deployments and products). Even when it implemented in the router, there would need to be a mechanism to share the state of IP->MAC address between the routers on the link.
Thus to solve that we need
4. DHCP server track MAC address to get IP->MAC binding

yes. so I have never heard about a case where a DHCP relay wasn't on the forwarding path.
relays or servers must in any case be on-link. I suggested above that we simplify the scenario (and discussion) by assuming the DHCP server was on-link and running on a router.

with regards to the IP -> MAC binding.
 - DHCP server gleans that information from ND/DHCP packets (e.g. RS) (ugly score of 3)
 - Hosts implement RFC6939 (ugly score of 2)
 - DHCP server uses normal address resolution to learn the L3/L2 mapping
The last choice implies a multicast NS from the DHCP server, right?

The idea was to avoid modifying hosts (by reusing DHCP) and reduce multicast - that seems to be hard.



5. Sharing of DHCP server state with all the routers on the link

yes, that's the trickiest part of this scheme.
this is a challenge whatever solution you choose here. even with ND register, where the proposal is for hosts to register with all on-link routers, you may get into a state where the databases aren't in sync. and also it forces hosts to quickly detect the appearance of a new router on the link.
efficient-nd (that you like to call nd register) is robust against database inconsistencies - eventual consistency.

If a new router appears and there are no use of multicast NS then the router needs to get the NCE database in any approach.
That could be using a yet-to-be-invented-and-standardized db sync protocol, vendor proprietary protocol, using unicast NS/NA between the routers, or involving the hosts as in ARO.

In all of those cases the new router might be asked to forward packets before it has a complete db. Might result in packets being dropped on the floor, or fallback to multicast NS to the hosts.

a fallback to normal ND is the only approach I can see off hand. for any solution we propose here.
I want to verify that I understand the context. Are you saying that any time there are two or more routers on the link we can not use the new scheme and can only use 4861? That doesn't make sense - we must aim higher.


With the above we still haven't addressed the unsolicited multicast RAs, thus we'd also need
6. Method to avoid multicast RAs - host driven unicast RS to refresh?

yes, that's independent of this I think. but as I think Andrew outlines in his document you can get reasonably far with that without host changes.


Note that if we solve 1, 5', and 6 we have a complete solution i.e.
1. solve how do reliably do implicit registrations from DAD (and data packets) in routers
5': sharing of that registration state (explicitly or implicitly) between the routers on the link
6. Method to avoid multicast RAs - host driven unicast RS to refresh?


Thus I don't see how "reusing DHCP" makes for less work - it seems to create a lot more  work by changing not only hosts and routers but also DHCP servers and DHCP relays plus defining additional need for state sharing which doesn't exist today.

if we need to put the state in the network, then I don't see that the maintaining network state for the L3/L2 mapping is different regardless of how you wrap the data.
Sorry, I don't understand your comment nor how it relates to the part of my text that you quoted.
Please explain.


[And as I've indicated, I think that #1 is actually hard even if there are products that do that with constrained applicability today. More about that later since it doesn't affect the difference between "reuse DHCP" and other parts of the solution space AFAICT.]

I think DHCP is largely a deployment choice. and that unless we agree on the assumptions, e.g. no legacy (which means we don't need 1) then I agree with you. DHCP as a solution only makes sense within certain constraints.

again I don't see how 6 isn't orthogonal to this. ah, sorry double negative. ;-)

4 and 5 are the biggest issues with a DHCP based solution.
no host changes, but definitely router/DHCP changes, and possibly AP changes.
Explain how a host which uses RFC 4941 address does not need changes.

      
DAD was invented largely to detect manual misconfiguration.

    

    No, it was actually a lot more about EUI-64 derived IIDs and the
    fact that some vendors had issued NICs which all had the same MAC
    addresses. Those rare situations were a pain to track down. Hence at
    or around the time of the 1st Stockholm IETF we came up with this
    single NUD probe.

    

    Since then we have temporary addresses, CGA, stable-privacy etc 
    which depend on DAD being able to detect duplicates.

    But manual misconfig never entered in the picture AFAIR.

    

      
as long as the network is assigning the address instead of the host, DAD isn't required.
the assigning entity could do the duplicate detection itself, and that it can do from its own valid source address.

    

    Yes, but that doesn't work with the security and privacy model for
    stable-privacy and CGA and their likes. Hence a non-starter AFAICT.

    

      

depending on network entities detecting a DAD message and using that to inject state in the network is a poor choice I think. DAD is unreliable, default DAD attempts is zero. 

    

    Default DAD attempts is one - not zero.

    But it isn't reliable in the case of random packet loss, spanning
    tree reconvergence triggering packet loss, sleeping hosts, etc, etc.

    

      
although it is sent as L2 unicast it will still have a typical failure rate of 1-5% on WIFI.

if we want network state for link-local addresses, and duplicate address detection, and also allow applications to use link-local addresses, then we need to 'figure' something out. I agree that without host changes that's tricky. while the network might detect and install state for the link-local address on e.g. RS/DHCP SOLICIT, the host might not be receptible to changing it after DAD has passed.

lots of good points here, do you collect them for a later draft?

    

    Yes, I'm trying to capture the design tradeoffs.

    Counting on you all to keep me honest ;-)

    

       Erik

    

    

      
 


      

      

      

      
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


    

    

  



From nobody Tue Feb 25 15:45:12 2014
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3461A07C2 for ; Tue, 25 Feb 2014 15:45:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level: 
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLJMYfVMOEnO for ; Tue, 25 Feb 2014 15:45:07 -0800 (PST)
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id 67EE41A01CB for ; Tue, 25 Feb 2014 15:45:07 -0800 (PST)
Received: from [192.168.10.18] ([78.204.24.4]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s1PNixFJ031770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Feb 2014 15:45:01 -0800
Message-ID: <530D2AFB.6090301@acm.org>
Date: Tue, 25 Feb 2014 15:44:59 -0800
From: Erik Nordmark 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: IETF IPv6 
Subject: Reading list for 6man ND discussion
Content-Type: multipart/alternative; boundary="------------030105040203070904060803"
X-Sonic-ID: C;aO3d1nae4xG1ttl8OBdzQA== M;4PaN13ae4xG1ttl8OBdzQA==
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/cmAIYSjalYSjkHwhT9zmEYfMVRE
Cc: 6man Chairs <6man-chairs@tools.ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Feb 2014 23:45:09 -0000

This is a multi-part message in MIME format.
--------------030105040203070904060803
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

We'll have 45 minutes in the 6man session to talk about ND. As the 
agenda indicates there are three parts:
  - problem statement
  - shorter term including operational and implementation advise
  - unsolved problems

To prepare for this session it would be good if folks read:
draft-vyncke-6man-mcast-not-efficient 

draft-yourtchenko-colitti-nd-reduce-multicast 

draft-chakrabarti-nordmark-6man-efficient-nd 


There is also some background information in RFC 6574 from an IAB workshop.

Regards,
    Erik


--------------030105040203070904060803
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    We'll have 45 minutes in the 6man session to talk about ND. As the
    agenda indicates there are three parts:

     - problem statement

     - shorter term including operational and implementation advise

     - unsolved problems

    

    To prepare for this session it would be good if folks read:

    
      draft-vyncke-6man-mcast-not-efficient
    

    
    draft-yourtchenko-colitti-nd-reduce-multicast
    
    

    draft-chakrabarti-nordmark-6man-efficient-nd
    

    

    There is also some background information in RFC 6574 from an IAB
    workshop.

    

    Regards,

       Erik

    

  


--------------030105040203070904060803--


From nobody Wed Feb 26 00:08:05 2014
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F361A0034 for ; Wed, 26 Feb 2014 00:07:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.348
X-Spam-Level: 
X-Spam-Status: No, score=-7.348 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yTsK430gTUq for ; Wed, 26 Feb 2014 00:07:53 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id D4DB31A003A for ; Wed, 26 Feb 2014 00:07:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9232; q=dns/txt; s=iport; t=1393402072; x=1394611672; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=phzS2a+LAsI/lvcsNi/s7CkVQeU6WRv6teb5C3um/Kc=; b=S7gbxLBJDrq2+9PNFJ4X1j8lU/UL0/PU9Ce8zx7zVdBA+yfB8zVdcpKY mt0pGpHi0LaNcCUBJ34hP7GhUpT4tCGEk1eCC/cFWzTT496U1G5N0YRpQ O9r5YUE8aOmkoyrKdfjtJQeqyhbvGuxq0mjeMRZWQn0sq9Bed+wa1foAZ U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAC2gDVOtJXG+/2dsb2JhbABQCIMGO8FcgRoWdIIlAQEBAwEBAQEkRwIJBQsCAQgYLicLJQIEDgWHfQgNyF8TBI14AiMzB4MkgRQEiRGLOoNrkiiDLYFo
X-IronPort-AV: E=Sophos;i="4.97,546,1389744000"; d="scan'208";a="23259558"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-3.cisco.com with ESMTP; 26 Feb 2014 08:07:51 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1Q87pQZ014696 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 08:07:51 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.84]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Wed, 26 Feb 2014 02:07:50 -0600
From: "Pascal Thubert (pthubert)" 
To: Erik Nordmark 
Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast
Thread-Topic: Comments on draft-yourtchenko-colitti-nd-reduce-multicast
Thread-Index: AQHPLg20SjVxfDziP0SiLTMeBLFIcJrGAflIgAE1mos=
Date: Wed, 26 Feb 2014 08:07:50 +0000
Message-ID: <4A7C4B57-8D55-48AE-AC8E-4D85768CDE7E@cisco.com>
References: <5305AF13.5060201@acm.org> <75B6FA9F576969419E42BECB86CB1B89115F99A9@xmb-rcd-x06.cisco.com>  <75B6FA9F576969419E42BECB86CB1B89115F9BAE@xmb-rcd-x06.cisco.com> , <530C9CFD.2000409@acm.org>
In-Reply-To: <530C9CFD.2000409@acm.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/vFsvW6RIQMFsF7iS9QMa9fJWvxg
Cc: "Andrew Yourtchenko \(ayourtch\)" , IETF IPv6 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2014 08:07:58 -0000

I can not find a reference to TOS bits or priority in 4861...

Certainly NUD should be higher priority than traffic?

Pascal

> Le 25 f=E9vr. 2014 =E0 14:39, "Erik Nordmark"  a =E9cri=
t :
>=20
>> On 2/21/14 12:36 PM, Andrew Yourtchenko wrote:
>>=20
>> Myself I did not like this portion of my reply with no quantifiable data=
 (because operating on a basis of a belief is not a good engineering).
>>=20
>> I happened to have a couple of hours of offline time, during which I tri=
ed to sketch the scenario and try to get as far as I can without building a=
 lab.
>>=20
>> It's a *very rough sketch*. If you think there can be parts that can be =
made better in it, tell me.
> Andrew,
> I like this sketch. A few comments below.
>>=20
>> The initial assumptions for this thought experiment are as follows:
>>=20
>> 1) We have 10000 clients in a single /64.
>>=20
>> 2) There are multiple APs that bridge the traffic from wired onto
>> wireless medium, with the client count limited to 100 per AP.
>>=20
>> 3) there is 20x speed difference between unicast transmission and
>> multicast transmission.: the effective multicast speed is assumed to be
>> 1 mbps, the effective unicast speed is assumed to be 20mbps data rate.
>>=20
>> 4) The APs are assumed to be "Naive" i.e. they do not perform any snoopi=
ng
>> nor multicast->unicast conversions, but at the same time they are able t=
o bridge the unicast traffic without flooding it between multiple access po=
ints. I.e. we assume a model where we have a single router (or an FHRP pair=
) and a set of 100 APs bridging the traffic.
>>=20
>> (Corollary from the above: The effective unicast capacity is 100*20mbps,=
 whereas the effective multicast capacity is 1*1Mbps, therefore the differe=
nce in throughput is 1000-fold).
>>=20
>> Let's first consider the steady state. Suppose each host downloads
>> a file at 0.1 mbps.  Within each AP, therefore we have a 50% capacity ut=
ilization (0.1*100 =3D 10Mbps, we have 20 Mbps capacity).
>>=20
>> It's easy to see this comfortably accomodates all the hosts. Obviuously
>> the unicast NUD in this traffic is fairly minimal, so I don't think it's=
 even worth to count how much it is.
>>=20
>> Now, lets look at a potential failure.
>>=20
>> At the time of the NUD probe, it's enough to lose the 3 retries,
>> spaced 1 second apart.  The default reachable time is 30 seconds,
>> with the random jitter of 0.5 of that.
>>=20
>> So, all that is needed to achieve a mass NUD failure is a ~30 second
>> outage during the period when all the hosts are sending the traffic.
>>=20
>> A reboot of the majority of the networking gear takes several times long=
er than this.
>>=20
>> Therefore, a crash of the default gateway during the peak hour is
>> a one guaranteed trigger for this to happen.
>>=20
>> So, now we have a situation of 10000 hosts which have deleted their defa=
ult gateway from the neighbor table, and send the multicast neighbor solici=
tations for it.
>>=20
>> Assume the NS is 64 bytes, 10000 hosts sending such a packet means 64 by=
tes * 8 bit * 10000 hosts =3D 5120000 bits/sec - or, 5 mbps.
> Just to make it clear, each NS retransmissions is 5 Mbits and the retrans=
mission time is 1 second. Hence with 4861 we get 5 mbps for 3 seconds. Howe=
ver, they hosts aren't that likely to all discover the NUD failure in the s=
ame 3 second window. With ReachableTime=3D30 seconds it depends on when the=
re last successful NUD probe or higher-level reachability advise can in. Hm=
m - with TCP the reachability advise might come with every left window edge=
 advancement i.e. they would synchronize quite closely.
>=20
>>=20
>> Note, that this is only the shared bandwidth downstream back to the host=
s - the airtime spent by the upstream traffic is 20x faster, so I am gratui=
tously discarding it.
>>=20
>> Since the APs can not send the traffic at this rate, obviously, we will
>> need to drop some of it. Note, if the clients succeed with the ND to the=
 default gateway, they will start streaming data again, so the effective mu=
lticast throughput will drop to the 0.5 mbps as soon as the noticeable port=
ion of clients recovers.
> While the multicast NS will see downstream drops, what matters for the re=
solution is that the router receives it and responds. Thus why wouldn't tha=
t part work?
> The NA from the router will be unicast so if that unicast isn't dropped d=
ue to the multicasts then it should resolve quickly. I don't know if unicas=
t is prioritized higher than multicast or not.
>=20
> (We'll see downstream overload due to the multicasts, but that might just=
 last for 1 second if the NS/NA to/from the router gets through.)
>=20
>>=20
>> Let's assume the best case of 20% of the clients managing to recover wit=
hin the first second.
>>=20
>> As we are approaching full recovery, the lesser number of clients will b=
e able to get their multicast NS sent because the airtime is being taken by=
 the payload traffic. Anyway, let's discard that and assume that every seco=
nd 20% of the clients will recover.
>>=20
>> This means that the recovery of the full set of the clients in this cond=
itions will take an *absolute* minimum of 5 seconds.
>>=20
>> Did I prove myself wrong ? Seems so. We can see that with some of the re=
laxed assumptions I took, the hosts seem to recover.
>>=20
>> But, let's add to this a little bit of mDNS, and other multicast-loving =
protocols, which tend to generate a fair chunk of traffic when they detect =
the network was "restored".
>>=20
>> This can shrink the available capacity several times. Add to this that t=
he host does not necessarily stream at 100kbps, but might have higher data =
rates, and I think we can consider the available
>> multicast capacity at startup to be 1/10th of what it is in theory.
> Yes, in general TCP will fill the pipe thus at each AP all of the downstr=
eam bandwidth will be used.
>=20
> But if the streaming comes via the default router (which crashed or was u=
nreachable for a few seconds), then the stream would also slow down due to =
TCP, in which case there is less of a multicast overload issue. There might=
 be cases where this TCP slowdown doesn't happen though.
>=20
>  Erik
>=20
>>=20
>> This is where the things may become interesting - 1/10th of the capacity=
 means that it will take not 5, but 50 seconds for all the hosts to recover=
.
>>=20
>> This means that the hosts which recovered in the very first second, will=
 already be sending NUD traffic while the network is still under stress. If=
 these packets are lost, the hosts might back into the pool of the "orphans=
" who are sending the multicast, because they delete their neighbor entry.
>>=20
>> There are some other things to consider:
>>=20
>> - I deliberately kept the scenario here with *one* ND entry.
>> Assuming your hosts are talking with 3-4 other hosts besides the default=
 gateway. This increases the load and proportionally makes the dangerous st=
ate easier to achieve.
>>=20
>> - another factor that I am omitting - that such a storm of ND onto the d=
efault gateway might cause rate-limiting of the control plane packets on th=
e gateway. With some of the limits being as low as 1000pps, this might give=
 a recovery time on the order of minutes even without the wireless multicas=
t being the bottleneck, yet still resulting in a lot of multicast NS in the=
 air still during the slow recovery.
>>=20
>> This is about as precise of the construct I can build.
>>=20
>> Is it perfect ? No, by no means. It also does assume that in the case of=
 the default gateway the wireless performance will be limiting factor - I t=
hink it won't - so it's more of an appropriate scenario for a case of a p2p=
 communications on the network. The default-gateway-only will be inherently=
 much more stable, I think - because the multicast on the wired side is fas=
t, so the drops on the wireless side will not matter.
>>=20
>> It's probably worth it to change the text into "There is potential for t=
he failing NUD to *contribute* to a longer recovery and possible creation o=
f the locked situation in the case of flash failure - but the exact quantif=
ication of the impact in such an environment is a topic of further study".
>>=20
>> And then maybe I could dump the above thought experiment into a separate=
 draft, to see if the folks could contribute to the experiment / maybe some=
one could run it - and reference it in this item ?
>>=20
>> It seems like an interesting area to dig a bit more in - creating a suit=
able model and playing with the parameters to see where it breaks seems lik=
e a useful exercise to understand how many hosts can there be in a single /=
64 on WiFi with a "naive" set of access-points.
>>=20
>> Thoughts ?
>>=20
>> --a
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Wed Feb 26 03:31:29 2014
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAFDE1A0272 for ; Wed, 26 Feb 2014 03:31:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.252
X-Spam-Level: 
X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9salVlHfLwU for ; Wed, 26 Feb 2014 03:31:19 -0800 (PST)
Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE681A0057 for ; Wed, 26 Feb 2014 03:31:19 -0800 (PST)
Received: from dhcp-10-61-101-160.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 8BC84612C; Wed, 26 Feb 2014 03:31:15 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_BF31B731-687A-4D98-9A5E-9752B81FE405"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast
From: Ole Troan 
In-Reply-To: <530D10C2.3080208@acm.org>
Date: Wed, 26 Feb 2014 11:31:13 +0000
Message-Id: <847BE1A6-1A6F-4265-BF4A-67AD87504EDC@employees.org>
References: <5305AF13.5060201@acm.org> <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org> <530BCF83.4090500@acm.org>  <530CAC9D.1040105@acm.org> <2CFB5723-A676-4ADD-B555-83752997CFD7@employees.org> <530D10C2.3080208@acm.org>
To: Erik Nordmark 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/2yXU9lnuaJc5vCKvPDsa1N5R62Y
Cc: Andrew Yourtchenko , 6man WG 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2014 11:31:26 -0000

--Apple-Mail=_BF31B731-687A-4D98-9A5E-9752B81FE405
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Erik,

>> So a potential approach would be to have the host form its address =
using the SLAAC method it prefers (such as stable-privacy) and then go =
through the DHCP (discovery plus request/response having the IA_NA/TA =
with the formed address). I don't know if we can use the 2 packet DHCP =
exchange for this or need the 4 packet one.  The host would get =
lifetimes back from the DHCP server so it would know when it needs to =
renew.
>>=20
>> you could only use 2 message exchange if there was a single DHCP =
server on the link.
> I guess the host would need to do the discover once, but then can do =
each address registration with just 2 messages.

after discovery the other protocol exchanges are 2 message.
that should be the same as efficient ND. first you discover the routers, =
then you exchange messages with chosen routers.=20

>>> If all the hosts on the link were to do this, and the DHCP service =
is 100% reliable, then this would ensure no duplicates.
>>> But it has issues with incremental deployment where some hosts do =
this but not the legacy hosts, since the legacy hosts would do current =
DAD probes and not find out about the addresses registered with the DHCP =
server. If the DHCP server is on-link it could proxy respond (and also =
implicitly learn about registrations from those DAD probes - with the =
limitations for implicit registrations which I'm trying to write down), =
but what about the case of DHCP relay(s) on the link and an off-link =
DHCP server?
>>>=20
>> DHCP always has an on-link presence, be it the relay or the server. =
in theory (which is very far from practice), relays are stateless. for =
this discussion I suggest we assume DHCP must be deployed so that there =
is a DHCP server on-link and on every router.
> You can't have it on every router unless there is a server-server =
protocol to coordinate the address assignments/registrations between the =
routers that are on the same link. There is no IETF standard for this =
(it was discussed and abandoned in the DHC WG a long time back).

there is work apparently on failover:
RFC7031
draft-ietf-dhc-dhcpv6-failover-design

by moving the state into the network, maintaining that state on all =
first-hop router is going to be a challenge. that is the same problem, =
if you use DHCP or if you use ND.

>> with regards to your legacy point, with DHCP we can "declare" that =
there is no legacy. if you want to connect to networks like these, then =
DHCP is the only option for address assignment. just like there are =
networks deployed like that today.
>>=20
> I fear you are equating DHCPv6 as implemented by hosts today, and the =
extensions on the hosts necessary to use DHCP for address registrations. =
If you say that you will only support hosts that implement DHCP address =
registrations (for all addresses SLAAC - 4941, stable-privacy, microsoft =
privacy addresses, etc) then you will support no hosts at all on those =
links.
>=20
> That sounds like a non starter to me.

you are quick to jump to conclusions. ;-)
I think we need to separate what _can_ be done within the protocol and =
how the protocol is deployed today.

in DHCP as deployed today, you get address assignment. what addresses =
are assigned to hosts is defined in the address assignment policy on the =
DHCP server. just like on any other network that uses DHCP for address =
assignment.

is it really a requirement that hosts must generate addresses? if so =
why? what problem does that solve in this context?

>>> In that case it seems like the DHCP relays need to relay all DAD =
packets to the DHCP server, so that it can respond (duplicate or ok), =
and build it state.
>>>=20
>> any scheme we can find that has no or few legacy implications would =
be good.
>> in the above scheme with the deployment restrictions outlined, DAD =
messages could be silently dropped at the AP/router.
>>=20
>>=20
>>> And should the DHCP service loose some or all of its state (e.g., a =
cold standby is started after a hardware failure) then it doesn't have a =
way to rebuild its state from the network until the lifetimes cause the =
new hosts to renew. And for legacy hosts the DHCP server/relay would =
need to glean on data packets to reliably find out about addresses that =
are in use since the legacy host do not "renew" with an additional DAD =
probe in a predictable time.
>>>=20
>> I agree that DHCP performs poorly with regards to "server initiated" =
messages.
>> after a state-loss event you could do one of (again assuming no host =
changes):
>>  - DHCP bulk lease query
>>=20
> Who would respond to that? There is no relay in your picture as I =
understand it.
>>  - fall back to normal ND behaviour
> When the DHCP server or router crashes it typically starts clean, =
hence it doesn't know whether it lost state, or is a newly =
installed/configured node. Thus it wouldn't be "fall back" AFAICT, but =
actually a requirement to always start in normal ND behavior and then =
somehow move towards DHCP address registrations.
>=20
> You probably want to walk through all the details and write down the =
proposal - more efficient than me trying to guess and second guess how =
you think it might work and poke holes at my own guesses.

right, maintaining this state is the crux of the problem. which is also =
the main reason why I'm skeptical about efficient ND.

>>  - low timers
>>  - learn DHCP database from neighbouring routers
>>=20
>>=20
>>> Thus it seems like in order to solve DAD using DHCPv6 we need to
>>> 1. solve how do reliably do implicit registrations from DAD (and =
data packets?) for legacy hosts in DHCP relay/server
>>> 2. new interaction between DHCP relay and server to handle legacy =
hosts in normal operation
>>> 3. ditto in the case of DHCP server state loss
>>>=20
>> I don't think we should go there, and if that's where we want to go, =
then I'm much more open at looking at new approaches.
>>=20
> I don't see how you can support legacy hosts without that. We can't =
assume that legacy hosts do DHCP address registrations for RFC 4941 =
temporary addresses when the A flag is set. Clearing the A flag means =
that some legacy hosts will not work on those links.

as above. legacy hosts get address assignment, hosts that care about =
self generating interface identifiers will get address registration (if =
allowed by network policy).

>>> Note that this doesn't remove the need to multicast Neighbor =
Solutions for address resolutions, since the DHCP server or relay is not =
required to be implemented in the router (it might be in some =
deployments and products). Even when it implemented in the router, there =
would need to be a mechanism to share the state of IP->MAC address =
between the routers on the link.
>>> Thus to solve that we need
>>> 4. DHCP server track MAC address to get IP->MAC binding
>>>=20
>> yes. so I have never heard about a case where a DHCP relay wasn't on =
the forwarding path.
>> relays or servers must in any case be on-link. I suggested above that =
we simplify the scenario (and discussion) by assuming the DHCP server =
was on-link and running on a router.
>>=20
>> with regards to the IP -> MAC binding.
>>  - DHCP server gleans that information from ND/DHCP packets (e.g. RS) =
(ugly score of 3)
>>  - Hosts implement RFC6939 (ugly score of 2)
>>  - DHCP server uses normal address resolution to learn the L3/L2 =
mapping
>>=20
> The last choice implies a multicast NS from the DHCP server, right?
>=20
> The idea was to avoid modifying hosts (by reusing DHCP) and reduce =
multicast - that seems to be hard.

yes, but it would only be on initial connect.
I think Andrew would argue that you can achieve the same optimisation by =
increasing the reachable timers.
full circle. ;-)

>>> 5. Sharing of DHCP server state with all the routers on the link
>>>=20
>> yes, that's the trickiest part of this scheme.
>> this is a challenge whatever solution you choose here. even with ND =
register, where the proposal is for hosts to register with all on-link =
routers, you may get into a state where the databases aren't in sync. =
and also it forces hosts to quickly detect the appearance of a new =
router on the link.
>>=20
> efficient-nd (that you like to call nd register) is robust against =
database inconsistencies - eventual consistency.=20
>=20
> If a new router appears and there are no use of multicast NS then the =
router needs to get the NCE database in any approach.=20
> That could be using a yet-to-be-invented-and-standardized db sync =
protocol, vendor proprietary protocol, using unicast NS/NA between the =
routers, or involving the hosts as in ARO.
>=20
> In all of those cases the new router might be asked to forward packets =
before it has a complete db. Might result in packets being dropped on =
the floor, or fallback to multicast NS to the hosts.

yes, it is the yet-to-be-invented that scares me.

>> a fallback to normal ND is the only approach I can see off hand. for =
any solution we propose here.
>>=20
> I want to verify that I understand the context. Are you saying that =
any time there are two or more routers on the link we can not use the =
new scheme and can only use 4861? That doesn't make sense - we must aim =
higher.

write it down.
might be my Scandinavian pessimism (which I assume you share), I'm not =
too hopeful on simple solutions here.
if you can assume the routers are wired, then you could run a routing =
protocol to advertise the bindings between themselves. sounds like we =
have a bar bof, napkin, pen and beer required for this part of the =
discussion. ;-)

>>> With the above we still haven't addressed the unsolicited multicast =
RAs, thus we'd also need
>>> 6. Method to avoid multicast RAs - host driven unicast RS to =
refresh?
>>>=20
>> yes, that's independent of this I think. but as I think Andrew =
outlines in his document you can get reasonably far with that without =
host changes.
>>=20
>>=20
>>> Note that if we solve 1, 5', and 6 we have a complete solution i.e.
>>> 1. solve how do reliably do implicit registrations from DAD (and =
data packets) in routers
>>> 5': sharing of that registration state (explicitly or implicitly) =
between the routers on the link
>>> 6. Method to avoid multicast RAs - host driven unicast RS to =
refresh?
>>>=20
>>>=20
>>> Thus I don't see how "reusing DHCP" makes for less work - it seems =
to create a lot more  work by changing not only hosts and routers but =
also DHCP servers and DHCP relays plus defining additional need for =
state sharing which doesn't exist today.
>>>=20
>> if we need to put the state in the network, then I don't see that the =
maintaining network state for the L3/L2 mapping is different regardless =
of how you wrap the data.
> Sorry, I don't understand your comment nor how it relates to the part =
of my text that you quoted.
> Please explain.

same as above. maintaining synchronized state across all first-hop =
routes for sleepy nodes, needs some thought.
regardless of the wrapping (ND or DHCP) of the bits on the wire between =
host and router.


>>> [And as I've indicated, I think that #1 is actually hard even if =
there are products that do that with constrained applicability today. =
More about that later since it doesn't affect the difference between =
"reuse DHCP" and other parts of the solution space AFAICT.]
>>>=20
>> I think DHCP is largely a deployment choice. and that unless we agree =
on the assumptions, e.g. no legacy (which means we don't need 1) then I =
agree with you. DHCP as a solution only makes sense within certain =
constraints.
>>=20
>> again I don't see how 6 isn't orthogonal to this. ah, sorry double =
negative. ;-)
>>=20
>> 4 and 5 are the biggest issues with a DHCP based solution.
>> no host changes, but definitely router/DHCP changes, and possibly AP =
changes.
>>=20
> Explain how a host which uses RFC 4941 address does not need changes.

it uses IA_TA. no change.

>> DAD was invented largely to detect manual misconfiguration.
> No, it was actually a lot more about EUI-64 derived IIDs and the fact =
that some vendors had issued NICs which all had the same MAC addresses. =
Those rare situations were a pain to track down. Hence at or around the =
time of the 1st Stockholm IETF we came up with this single NUD probe.
>=20
> Since then we have temporary addresses, CGA, stable-privacy etc  which =
depend on DAD being able to detect duplicates.
> But manual misconfig never entered in the picture AFAIR.

OK, that I got from Steve, and is probably the assignment type with the =
biggest probability of collision.

>> as long as the network is assigning the address instead of the host, =
DAD isn't required.
>> the assigning entity could do the duplicate detection itself, and =
that it can do from its own valid source address.
>>=20
> Yes, but that doesn't work with the security and privacy model for =
stable-privacy and CGA and their likes. Hence a non-starter AFAICT.

privacy addresses are supported in DHCP.
I don't understand the requirement for supporting CGA, I think there =
have been proposals for CGA and DHCP.
we need to go back and understand the requirements. with the DHCP hint =
mechanism the hosts can in any case suggest a CGA address to use. for =
both efficient ND and DHCP the "network" is in control if which =
addresses the hosts are allowed to use.


>> depending on network entities detecting a DAD message and using that =
to inject state in the network is a poor choice I think. DAD is =
unreliable, default DAD attempts is zero.=20
>>=20
> Default DAD attempts is one - not zero.

yes, of course. "might as well have been zero". ;-)

> But it isn't reliable in the case of random packet loss, spanning tree =
reconvergence triggering packet loss, sleeping hosts, etc, etc.
>> although it is sent as L2 unicast it will still have a typical =
failure rate of 1-5% on WIFI.
>>=20
>> if we want network state for link-local addresses, and duplicate =
address detection, and also allow applications to use link-local =
addresses, then we need to 'figure' something out. I agree that without =
host changes that's tricky. while the network might detect and install =
state for the link-local address on e.g. RS/DHCP SOLICIT, the host might =
not be receptible to changing it after DAD has passed.
>>=20
>> lots of good points here, do you collect them for a later draft?
>>=20
> Yes, I'm trying to capture the design tradeoffs.
> Counting on you all to keep me honest ;-)

cheers,
Ole


--Apple-Mail=_BF31B731-687A-4D98-9A5E-9752B81FE405
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

iQEcBAEBCgAGBQJTDdCCAAoJEFuJXizso86gFdQH/j61o0Z3XOv6z7lt2BM7LRHK
0+5kfAhxTW/cdQclP6Eb7ytdKW+T1JgNuf2NlleQ/iQvtDjzXap5gNIxY9ZSYEpc
6ifPYi2IFVt4WW/QqYbC2I1Lj2fq7hzjlxuj4y24FrCW/MN+HtvgJoyvMYIoEyKn
h5dS1oUBxWE6pk/P/hkPsrX7eV6Y9bKPbnQT80tC29wAuQB9eFkT0hbOxJFOsClV
hzVxXotTNWZecPLjtomqCdnzEkwjbdgc4zeUdPLrpPpp7guTK3kTU4iDhuLFzNG7
ROBkxjmYkp8VOEiKLjTlkoWlgPiL1bD0f/rphp+G3rcZED+e4fuD7ZJaOTHQy2A=
=YyoO
-----END PGP SIGNATURE-----

--Apple-Mail=_BF31B731-687A-4D98-9A5E-9752B81FE405--


From nobody Wed Feb 26 04:04:29 2014
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7651A0190 for ; Wed, 26 Feb 2014 04:04:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.048
X-Spam-Level: 
X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GomZwEzKIurF for ; Wed, 26 Feb 2014 04:04:26 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id DA2461A0040 for ; Wed, 26 Feb 2014 04:04:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=602; q=dns/txt; s=iport; t=1393416265; x=1394625865; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CCkBfuaFn9fu26BM9QaTKsbp4s43wB9ujc6Lyfnbxhs=; b=atkEFHrqIZgHnj+zwybbPgY2QDoN7Zd+FvdyGq9iNXKYGuKKrCB2uOUf VpR+N5RRkvtXzs6EpOpczJ48ONU0RRj2o2m302t9hHsvRzpL61THVILDB XAx604I70qVAusngvYem7wqmxFqAYK/RI9Y/c8CQH7r6EVQUqKZwIDPkw 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcFAFDXDVOtJV2a/2dsb2JhbABZgwaBEsBzgR0WdIInAQEBBDo/DAQCAQgRBAEBCxQQMh0IAgQBDQ2HcckeF44jMQcGgx2BFAEDql6DLYIq
X-IronPort-AV: E=Sophos;i="4.97,547,1389744000"; d="scan'208";a="23303676"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 26 Feb 2014 12:04:24 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1QC4O0Q031951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 12:04:24 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Wed, 26 Feb 2014 06:04:24 -0600
From: "Hemant Singh (shemant)" 
To: "Pascal Thubert (pthubert)" , Erik Nordmark 
Subject: RE: Comments on draft-yourtchenko-colitti-nd-reduce-multicast
Thread-Topic: Comments on draft-yourtchenko-colitti-nd-reduce-multicast
Thread-Index: AQHPLg2r7NCj0C4O60mg5b5bMD7HkJrGAflIgAE1mouAAEFtUA==
Date: Wed, 26 Feb 2014 12:04:23 +0000
Message-ID: <75B6FA9F576969419E42BECB86CB1B89115FF161@xmb-rcd-x06.cisco.com>
References: <5305AF13.5060201@acm.org> <75B6FA9F576969419E42BECB86CB1B89115F99A9@xmb-rcd-x06.cisco.com>  <75B6FA9F576969419E42BECB86CB1B89115F9BAE@xmb-rcd-x06.cisco.com> , <530C9CFD.2000409@acm.org> <4A7C4B57-8D55-48AE-AC8E-4D85768CDE7E@cisco.com>
In-Reply-To: <4A7C4B57-8D55-48AE-AC8E-4D85768CDE7E@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.86.247.221]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/7Fvn5O_14rKMhCqJHFTh9xXSv_U
Cc: "Andrew Yourtchenko \(ayourtch\)" , IETF IPv6 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2014 12:04:27 -0000

One option is to use new ethertype for ND packets and have the access-point=
 provide downstream qos to this ethertype.   The hosts also filter ND traff=
ic using the new ethertype. =20

Hemant

-----Original Message-----
From: Pascal Thubert (pthubert)=20
Sent: Wednesday, February 26, 2014 3:08 AM
To: Erik Nordmark
Cc: Andrew Yourtchenko (ayourtch); Hemant Singh (shemant); IETF IPv6
Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast

I can not find a reference to TOS bits or priority in 4861...

Certainly NUD should be higher priority than traffic?

Pascal


From nobody Wed Feb 26 05:44:59 2014
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61C21A033F for ; Wed, 26 Feb 2014 05:44:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level: 
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DU5tX-UgJsEZ for ; Wed, 26 Feb 2014 05:44:44 -0800 (PST)
Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2856E1A02F5 for ; Wed, 26 Feb 2014 05:44:44 -0800 (PST)
Received: by mail-qc0-f180.google.com with SMTP id i17so1287619qcy.25 for ; Wed, 26 Feb 2014 05:44:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=nNYptxu8CacNR0DXtusFU/2PfrLpsUIyxjCk1UNT+dQ=; b=AVMLuOF4czf6MUl86PQ4/s0Umk7SIIYNmR1qawR1TvxYy7ZqfQ7VlpTfVdq8JQyjWw zFLBEi9n7nKNgfKEI3i6qVBG6zybcHFy0xkFt2t3HLgFO9ylQRpBGzTJOqYpSwh2Lnfe TN9itiVzHMzws+eJCYuyM58spyrSWMFotDtP0j8dhgc+x0YAifemIXn5JLRL8D/CIUyJ XWDPJeLSkYkD2UOBMGlDm5ZzoIFup25fzYH1PG9y0mO87VlWJOOaV07XN7qCUWuooWRZ HEZvfwuC6/ioVsKDxPP7o0XC8i101P2RdVDWTpGL48b0feesD/qxZEZgBrRuPEHZi2I+ CqDA==
X-Received: by 10.140.87.172 with SMTP id r41mr7108464qgd.101.1393422282617; Wed, 26 Feb 2014 05:44:42 -0800 (PST)
Received: from [10.78.51.56] (mobile-198-228-194-043.mycingular.net. [198.228.194.43]) by mx.google.com with ESMTPSA id u20sm1096596qge.2.2014.02.26.05.44.33 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Feb 2014 05:44:41 -0800 (PST)
References: <5305AF13.5060201@acm.org> <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org> <530BCF83.4090500@acm.org>  <530CAC9D.1040105@acm.org> <2CFB5723-A676-4ADD-B555-83752997CFD7@employees.org> <530D10C2.3080208@acm.org> <847BE1A6-1A6F-4265-BF4A-67AD87504EDC@employees.org>
Mime-Version: 1.0 (1.0)
In-Reply-To: <847BE1A6-1A6F-4265-BF4A-67AD87504EDC@employees.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D7A18D1-70AB-423D-8E61-DD50BBF2CFB5@gmail.com>
X-Mailer: iPhone Mail (11B651)
From: Ralph Droms 
Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast
Date: Wed, 26 Feb 2014 08:44:30 -0500
To: Ole Troan 
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/MAXsIlY9QFzU0WV5EVVB8BdRhUs
Cc: Erik Nordmark , Andrew Yourtchenko , 6man WG 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2014 13:44:51 -0000

> On Feb 26, 2014, at 6:31 AM, Ole Troan  wrote:
>=20
> Erik,
>=20
>>> So a potential approach would be to have the host form its address using=
 the SLAAC method it prefers (such as stable-privacy) and then go through th=
e DHCP (discovery plus request/response having the IA_NA/TA with the formed a=
ddress). I don't know if we can use the 2 packet DHCP exchange for this or n=
eed the 4 packet one.  The host would get lifetimes back from the DHCP serve=
r so it would know when it needs to renew.
>>>=20
>>> you could only use 2 message exchange if there was a single DHCP server o=
n the link.
>> I guess the host would need to do the discover once, but then can do each=
 address registration with just 2 messages.
>=20
> after discovery the other protocol exchanges are 2 message.
> that should be the same as efficient ND. first you discover the routers, t=
hen you exchange messages with chosen routers.=20
>=20
>>>> If all the hosts on the link were to do this, and the DHCP service is 1=
00% reliable, then this would ensure no duplicates.
>>>> But it has issues with incremental deployment where some hosts do this b=
ut not the legacy hosts, since the legacy hosts would do current DAD probes a=
nd not find out about the addresses registered with the DHCP server. If the D=
HCP server is on-link it could proxy respond (and also implicitly learn abou=
t registrations from those DAD probes - with the limitations for implicit re=
gistrations which I'm trying to write down), but what about the case of DHCP=
 relay(s) on the link and an off-link DHCP server?
>>> DHCP always has an on-link presence, be it the relay or the server. in t=
heory (which is very far from practice), relays are stateless. for this disc=
ussion I suggest we assume DHCP must be deployed so that there is a DHCP ser=
ver on-link and on every router.
>> You can't have it on every router unless there is a server-server protoco=
l to coordinate the address assignments/registrations between the routers th=
at are on the same link. There is no IETF standard for this (it was discusse=
d and abandoned in the DHC WG a long time back).
>=20
> there is work apparently on failover:
> RFC7031
> draft-ietf-dhc-dhcpv6-failover-design
>=20
> by moving the state into the network, maintaining that state on all first-=
hop router is going to be a challenge. that is the same problem, if you use D=
HCP or if you use ND.

Or, the ND messages could be relayed to the DHCP server...

The relay could even snoop the assigned addresses (which is already done now=
 [?] for other purposes.

>=20
>>> with regards to your legacy point, with DHCP we can "declare" that there=
 is no legacy. if you want to connect to networks like these, then DHCP is t=
he only option for address assignment. just like there are networks deployed=
 like that today.
>> I fear you are equating DHCPv6 as implemented by hosts today, and the ext=
ensions on the hosts necessary to use DHCP for address registrations. If you=
 say that you will only support hosts that implement DHCP address registrati=
ons (for all addresses SLAAC - 4941, stable-privacy, microsoft privacy addre=
sses, etc) then you will support no hosts at all on those links.
>>=20
>> That sounds like a non starter to me.
>=20
> you are quick to jump to conclusions. ;-)
> I think we need to separate what _can_ be done within the protocol and how=
 the protocol is deployed today.
>=20
> in DHCP as deployed today, you get address assignment. what addresses are a=
ssigned to hosts is defined in the address assignment policy on the DHCP ser=
ver. just like on any other network that uses DHCP for address assignment
>=20
> is it really a requirement that hosts must generate addresses? if so why? w=
hat problem does that solve in this context?

So, legacy hosts can be assigned addresses w/o hints while registering hosts=
 send in the hint to indicate address registration.

>=20
>>>> In that case it seems like the DHCP relays need to relay all DAD packet=
s to the DHCP server, so that it can respond (duplicate or ok), and build it=
 state.
>>> any scheme we can find that has no or few legacy implications would be g=
ood.
>>> in the above scheme with the deployment restrictions outlined, DAD messa=
ges could be silently dropped at the AP/router.
>>>=20
>>>=20
>>>> And should the DHCP service loose some or all of its state (e.g., a col=
d standby is started after a hardware failure) then it doesn't have a way to=
 rebuild its state from the network until the lifetimes cause the new hosts t=
o renew. And for legacy hosts the DHCP server/relay would need to glean on d=
ata packets to reliably find out about addresses that are in use since the l=
egacy host do not "renew" with an additional DAD probe in a predictable time=
.
>>> I agree that DHCP performs poorly with regards to "server initiated" mes=
sages.
>>> after a state-loss event you could do one of (again assuming no host cha=
nges):
>>> - DHCP bulk lease query
>> Who would respond to that? There is no relay in your picture as I underst=
and it.
>>> - fall back to normal ND behaviour
>> When the DHCP server or router crashes it typically starts clean, hence i=
t doesn't know whether it lost state, or is a newly installed/configured nod=
e. Thus it wouldn't be "fall back" AFAICT, but actually a requirement to alw=
ays start in normal ND behavior and then somehow move towards DHCP address r=
egistrations.
>>=20
>> You probably want to walk through all the details and write down the prop=
osal - more efficient than me trying to guess and second guess how you think=
 it might work and poke holes at my own guesses.
>=20
> right, maintaining this state is the crux of the problem. which is also th=
e main reason why I'm skeptical about efficient ND.

...and DHCP already has tackled the problem of restoring state through lease=
query.

>=20
>>> - low timers
>>> - learn DHCP database from neighbouring routers
>>>=20
>>>=20
>>>> Thus it seems like in order to solve DAD using DHCPv6 we need to
>>>> 1. solve how do reliably do implicit registrations from DAD (and data p=
ackets?) for legacy hosts in DHCP relay/server
>>>> 2. new interaction between DHCP relay and server to handle legacy hosts=
 in normal operation
>>>> 3. ditto in the case of DHCP server state loss
>>> I don't think we should go there, and if that's where we want to go, the=
n I'm much more open at looking at new approaches.
>> I don't see how you can support legacy hosts without that. We can't assum=
e that legacy hosts do DHCP address registrations for RFC 4941 temporary add=
resses when the A flag is set. Clearing the A flag means that some legacy ho=
sts will not work on those links.

Hosts with no DHCP implementation at all?

>=20
> as above. legacy hosts get address assignment, hosts that care about self g=
enerating interface identifiers will get address registration (if allowed by=
 network policy).

I agree...

>=20
>>>> Note that this doesn't remove the need to multicast Neighbor Solutions f=
or address resolutions, since the DHCP server or relay is not required to be=
 implemented in the router (it might be in some deployments and products). E=
ven when it implemented in the router, there would need to be a mechanism to=
 share the state of IP->MAC address between the routers on the link.
>>>> Thus to solve that we need
>>>> 4. DHCP server track MAC address to get IP->MAC binding
>>> yes. so I have never heard about a case where a DHCP relay wasn't on the=
 forwarding path.
>>> relays or servers must in any case be on-link. I suggested above that we=
 simplify the scenario (and discussion) by assuming the DHCP server was on-l=
ink and running on a router.
>>>=20
>>> with regards to the IP -> MAC binding.
>>> - DHCP server gleans that information from ND/DHCP packets (e.g. RS) (ug=
ly score of 3)
>>> - Hosts implement RFC6939 (ugly score of 2)
>>> - DHCP server uses normal address resolution to learn the L3/L2 mapping
>> The last choice implies a multicast NS from the DHCP server, right?
>>=20
>> The idea was to avoid modifying hosts (by reusing DHCP) and reduce multic=
ast - that seems to be hard.
>=20
> yes, but it would only be on initial connect.
> I think Andrew would argue that you can achieve the same optimisation by i=
ncreasing the reachable timers.
> full circle. ;-)
>=20
>>>> 5. Sharing of DHCP server state with all the routers on the link
>>> yes, that's the trickiest part of this scheme.
>>> this is a challenge whatever solution you choose here. even with ND regi=
ster, where the proposal is for hosts to register with all on-link routers, y=
ou may get into a state where the databases aren't in sync. and also it forc=
es hosts to quickly detect the appearance of a new router on the link.
>> efficient-nd (that you like to call nd register) is robust against databa=
se inconsistencies - eventual consistency.=20
>>=20
>> If a new router appears and there are no use of multicast NS then the rou=
ter needs to get the NCE database in any approach.=20
>> That could be using a yet-to-be-invented-and-standardized db sync protoco=
l, vendor proprietary protocol, using unicast NS/NA between the routers, or i=
nvolving the hosts as in ARO.
>>=20
>> In all of those cases the new router might be asked to forward packets be=
fore it has a complete db. Might result in packets being dropped on the floo=
r, or fallback to multicast NS to the hosts.
>=20
> yes, it is the yet-to-be-invented that scares me.

There may be something to learn about the sync protocol from work on DHCP sy=
nc.  We thought it was pretty straightforward until we got to the problem of=
 simultaneous updates between different host/server pairs.

>=20
>>> a fallback to normal ND is the only approach I can see off hand. for any=
 solution we propose here.
>> I want to verify that I understand the context. Are you saying that any t=
ime there are two or more routers on the link we can not use the new scheme a=
nd can only use 4861? That doesn't make sense - we must aim higher.
>=20
> write it down.
> might be my Scandinavian pessimism (which I assume you share), I'm not too=
 hopeful on simple solutions here.
> if you can assume the routers are wired, then you could run a routing prot=
ocol to advertise the bindings between themselves. sounds like we have a bar=
 bof, napkin, pen and beer required for this part of the discussion. ;-)

Where and when?

>=20
>>>> With the above we still haven't addressed the unsolicited multicast RAs=
, thus we'd also need
>>>> 6. Method to avoid multicast RAs - host driven unicast RS to refresh?
>>> yes, that's independent of this I think. but as I think Andrew outlines i=
n his document you can get reasonably far with that without host changes.
>>>=20
>>>=20
>>>> Note that if we solve 1, 5', and 6 we have a complete solution i.e.
>>>> 1. solve how do reliably do implicit registrations from DAD (and data p=
ackets) in routers
>>>> 5': sharing of that registration state (explicitly or implicitly) betwe=
en the routers on the link
>>>> 6. Method to avoid multicast RAs - host driven unicast RS to refresh?
>>>>=20
>>>>=20
>>>> Thus I don't see how "reusing DHCP" makes for less work - it seems to c=
reate a lot more  work by changing not only hosts and routers but also DHCP s=
ervers and DHCP relays plus defining additional need for state sharing which=
 doesn't exist today.
>>> if we need to put the state in the network, then I don't see that the ma=
intaining network state for the L3/L2 mapping is different regardless of how=
 you wrap the data.
>> Sorry, I don't understand your comment nor how it relates to the part of m=
y text that you quoted.
>> Please explain.
>=20
> same as above. maintaining synchronized state across all first-hop routes f=
or sleepy nodes, needs some thought.
> regardless of the wrapping (ND or DHCP) of the bits on the wire between ho=
st and router.

Yup.

>=20
>=20
>>>> [And as I've indicated, I think that #1 is actually hard even if there a=
re products that do that with constrained applicability today. More about th=
at later since it doesn't affect the difference between "reuse DHCP" and oth=
er parts of the solution space AFAICT.]
>>> I think DHCP is largely a deployment choice. and that unless we agree on=
 the assumptions, e.g. no legacy (which means we don't need 1) then I agree w=
ith you. DHCP as a solution only makes sense within certain constraints.
>>>=20
>>> again I don't see how 6 isn't orthogonal to this. ah, sorry double negat=
ive. ;-)
>>>=20
>>> 4 and 5 are the biggest issues with a DHCP based solution.
>>> no host changes, but definitely router/DHCP changes, and possibly AP cha=
nges.
>> Explain how a host which uses RFC 4941 address does not need changes.
>=20
> it uses IA_TA. no change.
>=20
>>> DAD was invented largely to detect manual misconfiguration.
>> No, it was actually a lot more about EUI-64 derived IIDs and the fact tha=
t some vendors had issued NICs which all had the same MAC addresses. Those r=
are situations were a pain to track down. Hence at or around the time of the=
 1st Stockholm IETF we came up with this single NUD probe.
>>=20
>> Since then we have temporary addresses, CGA, stable-privacy etc  which de=
pend on DAD being able to detect duplicates.
>> But manual misconfig never entered in the picture AFAIR.
>=20
> OK, that I got from Steve, and is probably the assignment type with the bi=
ggest probability of collision.
>=20
>>> as long as the network is assigning the address instead of the host, DAD=
 isn't required.
>>> the assigning entity could do the duplicate detection itself, and that i=
t can do from its own valid source address.
>> Yes, but that doesn't work with the security and privacy model for stable=
-privacy and CGA and their likes. Hence a non-starter AFAICT.
>=20
> privacy addresses are supported in DHCP.
> I don't understand the requirement for supporting CGA, I think there have b=
een proposals for CGA and DHCP.
> we need to go back and understand the requirements. with the DHCP hint mec=
hanism the hosts can in any case suggest a CGA address to use. for both effi=
cient ND and DHCP the "network" is in control if which addresses the hosts a=
re allowed to use.
>=20
>=20
>>> depending on network entities detecting a DAD message and using that to i=
nject state in the network is a poor choice I think. DAD is unreliable, defa=
ult DAD attempts is zero.
>> Default DAD attempts is one - not zero.
>=20
> yes, of course. "might as well have been zero". ;-)
>=20
>> But it isn't reliable in the case of random packet loss, spanning tree re=
convergence triggering packet loss, sleeping hosts, etc, etc.
>>> although it is sent as L2 unicast it will still have a typical failure r=
ate of 1-5% on WIFI.
>>>=20
>>> if we want network state for link-local addresses, and duplicate address=
 detection, and also allow applications to use link-local addresses, then we=
 need to 'figure' something out. I agree that without host changes that's tr=
icky. while the network might detect and install state for the link-local ad=
dress on e.g. RS/DHCP SOLICIT, the host might not be receptible to changing i=
t after DAD has passed.
>>>=20
>>> lots of good points here, do you collect them for a later draft?
>> Yes, I'm trying to capture the design tradeoffs.
>> Counting on you all to keep me honest ;-)
>=20
> cheers,
> Ole

- Ralph

>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Wed Feb 26 08:14:44 2014
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EA91A00FB for ; Wed, 26 Feb 2014 08:14:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.465
X-Spam-Level: *
X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATCZfacDLh3r for ; Wed, 26 Feb 2014 08:14:38 -0800 (PST)
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id AB9E71A0454 for ; Wed, 26 Feb 2014 08:12:51 -0800 (PST)
Received: from [192.168.10.18] ([78.204.24.4]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s1QGAfpx022933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Feb 2014 08:10:43 -0800
Message-ID: <530E1201.1020304@acm.org>
Date: Wed, 26 Feb 2014 08:10:41 -0800
From: Erik Nordmark 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Ole Troan 
Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast
References: <5305AF13.5060201@acm.org> <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org> <530BCF83.4090500@acm.org>  <530CAC9D.1040105@acm.org> <2CFB5723-A676-4ADD-B555-83752997CFD7@employees.org> <530D10C2.3080208@acm.org> <847BE1A6-1A6F-4265-BF4A-67AD87504EDC@employees.org>
In-Reply-To: <847BE1A6-1A6F-4265-BF4A-67AD87504EDC@employees.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Sonic-ID: C;viowigCf4xG0V9l8OBdzQA== M;bJHPigCf4xG0V9l8OBdzQA==
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/P7o0GFWqsZ7UujM2i6-tAnS1Sn0
Cc: Andrew Yourtchenko , 6man WG 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2014 16:14:40 -0000

On 2/26/14 3:31 AM, Ole Troan wrote:
>
> there is work apparently on failover:
> RFC7031
> draft-ietf-dhc-dhcpv6-failover-design
Good to know.
>
> by moving the state into the network, maintaining that state on all first-hop router is going to be a challenge. that is the same problem, if you use DHCP or if you use ND.

The difference being that for ARO there is a draft which specifies all 
the details for how to do it.

With DHCP there is at best a requirements and design document. And those 
do not address state sharing between DHCP relay, which we need if we 
want a complete solution (re)using DHCP.

>
>>> with regards to your legacy point, with DHCP we can "declare" that there is no legacy. if you want to connect to networks like these, then DHCP is the only option for address assignment. just like there are networks deployed like that today.
>>>
>> I fear you are equating DHCPv6 as implemented by hosts today, and the extensions on the hosts necessary to use DHCP for address registrations. If you say that you will only support hosts that implement DHCP address registrations (for all addresses SLAAC - 4941, stable-privacy, microsoft privacy addresses, etc) then you will support no hosts at all on those links.
>>
>> That sounds like a non starter to me.
> you are quick to jump to conclusions. ;-)
Not conclusions - but assumed requirements that incremental deployment 
is critical otherwise protocols don't get deployed.

You said "declare that there is no legacy" which sounds like an approach 
where only green-field deployment makes sense.
That is a non-starter to me  and not worth while.
> I think we need to separate what _can_ be done within the protocol and how the protocol is deployed today.
There are definitely separable considerations around reuse - one is 
reusing existing protocols without extensions. Another is to avoid 
modifying existing implementations of said protocols. A third is not 
modifying existing deployment practices.
>
> in DHCP as deployed today, you get address assignment. what addresses are assigned to hosts is defined in the address assignment policy on the DHCP server. just like on any other network that uses DHCP for address assignment.
>
> is it really a requirement that hosts must generate addresses? if so why? what problem does that solve in this context?
Privacy. (which is why we did RFC 3041 and stable-privacy-addr).

But we've only concluded in this thread that there is no addition needed 
to the DHCP standard to register host generated addresses using IA_TA.

There is a host implementation issue AFAICT - at least in ISC DHC it is 
not possible to feed a host generated address into the DHC client - it 
can only request that the server to *create* and assign temporary 
addresses (by using the '-T' option). I don't have source access to 
other DHC client code to check.

But the hosts would presumably need to change for other reasons if we go 
the DHCP path. There is no need to multicast DAD probes in that case, 
and getting rid of those multicasts would be helpful.
>
>>
>> When the DHCP server or router crashes it typically starts clean, hence it doesn't know whether it lost state, or is a newly installed/configured node. Thus it wouldn't be "fall back" AFAICT, but actually a requirement to always start in normal ND behavior and then somehow move towards DHCP address registrations.
>>
>> You probably want to walk through all the details and write down the proposal - more efficient than me trying to guess and second guess how you think it might work and poke holes at my own guesses.
> right, maintaining this state is the crux of the problem. which is also the main reason why I'm skeptical about efficient ND.
There is an internet draft for that.

I'm waiting for the similarely detailed draft for how to do this with 
DHCP ;-)

More seriously, I have spent the last day sketching on how this can be 
done reusing DHCP but it seems like either we need to invent  of new 
protocol mechanisms here and there, or we end up restricting things 
severely. The restrictions seem to be:
     - no support for DHCP relays - MUST have a DHCP server on every link
     - no support for redundant DHCP servers (until some standard DHC 
failover protocol has been specified and implemented)
     - can only support unmodified host implementations that have DHCP 
on the links that enable "efficient-dhcp"
     - can not support temporary addresses in unmodified hosts

I think we at least need to do better in terms of legacy host support.

>> efficient-nd (that you like to call nd register) is robust against database inconsistencies - eventual consistency.
>>
>> If a new router appears and there are no use of multicast NS then the router needs to get the NCE database in any approach.
>> That could be using a yet-to-be-invented-and-standardized db sync protocol, vendor proprietary protocol, using unicast NS/NA between the routers, or involving the hosts as in ARO.
>>
>> In all of those cases the new router might be asked to forward packets before it has a complete db. Might result in packets being dropped on the floor, or fallback to multicast NS to the hosts.
> yes, it is the yet-to-be-invented that scares me.
I don't know if you intended that comment as a critizism of efficient-nd 
or a more general comment. Efficient-nd is fully specified and ready for 
review. Much of it has already been implemented and tested in the form 
of RFC 6775.

The DHCP state sharing is yet-to-be-invented.

>
>>> a fallback to normal ND is the only approach I can see off hand. for any solution we propose here.
>>>
>> I want to verify that I understand the context. Are you saying that any time there are two or more routers on the link we can not use the new scheme and can only use 4861? That doesn't make sense - we must aim higher.
> write it down.
Huh? The above refers to your proposal in email about reusing DHCP. 
Seems like you should write down how you intended it to work so we can 
stop the guesswork.

> might be my Scandinavian pessimism (which I assume you share), I'm not too hopeful on simple solutions here.
If I ever had such pessimism I must have left it behind a long time ago.
It is not the decision to move forward to solve an important problem 
which is the issue - it is to work out the technical details that takes 
work - need to ensure that the protocol is robust, incrementally 
deployable,  introducing minimal complexity, etc.
> if you can assume the routers are wired, then you could run a routing protocol to advertise the bindings between themselves. sounds like we have a bar bof, napkin, pen and beer required for this part of the discussion. ;-)
See above - the devil is in the details.

>> Explain how a host which uses RFC 4941 address does not need changes.
> it uses IA_TA. no change.
Correct - no change to the DHC options, nor server. But the DHC client 
code and behavior needs to change. Needs to detect a duplicate (which 
the client can only tell by comparing the IA_TA it got from the server 
with what it sent in the IA_TA.) We probably also want to clarify that a 
server should honor the suggested IA_TA addresses unless it is a duplicate.

   Erik


From nobody Wed Feb 26 08:17:28 2014
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651781A0231 for ; Wed, 26 Feb 2014 08:17:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.465
X-Spam-Level: *
X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpXftYhC8ofD for ; Wed, 26 Feb 2014 08:17:16 -0800 (PST)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id BFD601A00B6 for ; Wed, 26 Feb 2014 08:17:16 -0800 (PST)
Received: from [192.168.10.18] ([78.204.24.4]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s1QFWsr1020091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Feb 2014 07:32:56 -0800
Message-ID: <530E0925.5030801@acm.org>
Date: Wed, 26 Feb 2014 07:32:53 -0800
From: Erik Nordmark 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Pascal Thubert (pthubert)" 
Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast
References: <5305AF13.5060201@acm.org> <75B6FA9F576969419E42BECB86CB1B89115F99A9@xmb-rcd-x06.cisco.com>  <75B6FA9F576969419E42BECB86CB1B89115F9BAE@xmb-rcd-x06.cisco.com> , <530C9CFD.2000409@acm.org> <4A7C4B57-8D55-48AE-AC8E-4D85768CDE7E@cisco.com>
In-Reply-To: <4A7C4B57-8D55-48AE-AC8E-4D85768CDE7E@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Sonic-ID: C;yJIKQ/ue4xGt95IjCY+HFQ== M;KMC9Q/ue4xGt95IjCY+HFQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/uAzPKKudCSNTzrGCf5qFDlEVoio
Cc: "Andrew Yourtchenko \(ayourtch\)" , IETF IPv6 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2014 16:17:19 -0000

On 2/26/14 12:07 AM, Pascal Thubert (pthubert) wrote:
> I can not find a reference to TOS bits or priority in 4861...
>
> Certainly NUD should be higher priority than traffic?
I don't think the question has come up in the past.
No harm in using a different TClass for Neighbor Discovery and/or 
different L2 priority (e.g., 802.1p).

But it might not make much of a difference if the main point where the 
priority matters is on the receiving host or router when it passes the 
packet to the CPU. For that the local implementation-specific mechanisms 
can presumably determine that it is an ND packet and queue/process it 
appropriately.

RFC 6583 talks about even finer grain prioritization for ND traffic - 
without any use of TClass or 802.1p.

Regards,
    Erik

>
> Pascal
>
>> Le 25 févr. 2014 à 14:39, "Erik Nordmark"  a écrit :
>>
>>> On 2/21/14 12:36 PM, Andrew Yourtchenko wrote:
>>>
>>> Myself I did not like this portion of my reply with no quantifiable data (because operating on a basis of a belief is not a good engineering).
>>>
>>> I happened to have a couple of hours of offline time, during which I tried to sketch the scenario and try to get as far as I can without building a lab.
>>>
>>> It's a *very rough sketch*. If you think there can be parts that can be made better in it, tell me.
>> Andrew,
>> I like this sketch. A few comments below.
>>> The initial assumptions for this thought experiment are as follows:
>>>
>>> 1) We have 10000 clients in a single /64.
>>>
>>> 2) There are multiple APs that bridge the traffic from wired onto
>>> wireless medium, with the client count limited to 100 per AP.
>>>
>>> 3) there is 20x speed difference between unicast transmission and
>>> multicast transmission.: the effective multicast speed is assumed to be
>>> 1 mbps, the effective unicast speed is assumed to be 20mbps data rate.
>>>
>>> 4) The APs are assumed to be "Naive" i.e. they do not perform any snooping
>>> nor multicast->unicast conversions, but at the same time they are able to bridge the unicast traffic without flooding it between multiple access points. I.e. we assume a model where we have a single router (or an FHRP pair) and a set of 100 APs bridging the traffic.
>>>
>>> (Corollary from the above: The effective unicast capacity is 100*20mbps, whereas the effective multicast capacity is 1*1Mbps, therefore the difference in throughput is 1000-fold).
>>>
>>> Let's first consider the steady state. Suppose each host downloads
>>> a file at 0.1 mbps.  Within each AP, therefore we have a 50% capacity utilization (0.1*100 = 10Mbps, we have 20 Mbps capacity).
>>>
>>> It's easy to see this comfortably accomodates all the hosts. Obviuously
>>> the unicast NUD in this traffic is fairly minimal, so I don't think it's even worth to count how much it is.
>>>
>>> Now, lets look at a potential failure.
>>>
>>> At the time of the NUD probe, it's enough to lose the 3 retries,
>>> spaced 1 second apart.  The default reachable time is 30 seconds,
>>> with the random jitter of 0.5 of that.
>>>
>>> So, all that is needed to achieve a mass NUD failure is a ~30 second
>>> outage during the period when all the hosts are sending the traffic.
>>>
>>> A reboot of the majority of the networking gear takes several times longer than this.
>>>
>>> Therefore, a crash of the default gateway during the peak hour is
>>> a one guaranteed trigger for this to happen.
>>>
>>> So, now we have a situation of 10000 hosts which have deleted their default gateway from the neighbor table, and send the multicast neighbor solicitations for it.
>>>
>>> Assume the NS is 64 bytes, 10000 hosts sending such a packet means 64 bytes * 8 bit * 10000 hosts = 5120000 bits/sec - or, 5 mbps.
>> Just to make it clear, each NS retransmissions is 5 Mbits and the retransmission time is 1 second. Hence with 4861 we get 5 mbps for 3 seconds. However, they hosts aren't that likely to all discover the NUD failure in the same 3 second window. With ReachableTime=30 seconds it depends on when there last successful NUD probe or higher-level reachability advise can in. Hmm - with TCP the reachability advise might come with every left window edge advancement i.e. they would synchronize quite closely.
>>
>>> Note, that this is only the shared bandwidth downstream back to the hosts - the airtime spent by the upstream traffic is 20x faster, so I am gratuitously discarding it.
>>>
>>> Since the APs can not send the traffic at this rate, obviously, we will
>>> need to drop some of it. Note, if the clients succeed with the ND to the default gateway, they will start streaming data again, so the effective multicast throughput will drop to the 0.5 mbps as soon as the noticeable portion of clients recovers.
>> While the multicast NS will see downstream drops, what matters for the resolution is that the router receives it and responds. Thus why wouldn't that part work?
>> The NA from the router will be unicast so if that unicast isn't dropped due to the multicasts then it should resolve quickly. I don't know if unicast is prioritized higher than multicast or not.
>>
>> (We'll see downstream overload due to the multicasts, but that might just last for 1 second if the NS/NA to/from the router gets through.)
>>
>>> Let's assume the best case of 20% of the clients managing to recover within the first second.
>>>
>>> As we are approaching full recovery, the lesser number of clients will be able to get their multicast NS sent because the airtime is being taken by the payload traffic. Anyway, let's discard that and assume that every second 20% of the clients will recover.
>>>
>>> This means that the recovery of the full set of the clients in this conditions will take an *absolute* minimum of 5 seconds.
>>>
>>> Did I prove myself wrong ? Seems so. We can see that with some of the relaxed assumptions I took, the hosts seem to recover.
>>>
>>> But, let's add to this a little bit of mDNS, and other multicast-loving protocols, which tend to generate a fair chunk of traffic when they detect the network was "restored".
>>>
>>> This can shrink the available capacity several times. Add to this that the host does not necessarily stream at 100kbps, but might have higher data rates, and I think we can consider the available
>>> multicast capacity at startup to be 1/10th of what it is in theory.
>> Yes, in general TCP will fill the pipe thus at each AP all of the downstream bandwidth will be used.
>>
>> But if the streaming comes via the default router (which crashed or was unreachable for a few seconds), then the stream would also slow down due to TCP, in which case there is less of a multicast overload issue. There might be cases where this TCP slowdown doesn't happen though.
>>
>>   Erik
>>
>>> This is where the things may become interesting - 1/10th of the capacity means that it will take not 5, but 50 seconds for all the hosts to recover.
>>>
>>> This means that the hosts which recovered in the very first second, will already be sending NUD traffic while the network is still under stress. If these packets are lost, the hosts might back into the pool of the "orphans" who are sending the multicast, because they delete their neighbor entry.
>>>
>>> There are some other things to consider:
>>>
>>> - I deliberately kept the scenario here with *one* ND entry.
>>> Assuming your hosts are talking with 3-4 other hosts besides the default gateway. This increases the load and proportionally makes the dangerous state easier to achieve.
>>>
>>> - another factor that I am omitting - that such a storm of ND onto the default gateway might cause rate-limiting of the control plane packets on the gateway. With some of the limits being as low as 1000pps, this might give a recovery time on the order of minutes even without the wireless multicast being the bottleneck, yet still resulting in a lot of multicast NS in the air still during the slow recovery.
>>>
>>> This is about as precise of the construct I can build.
>>>
>>> Is it perfect ? No, by no means. It also does assume that in the case of the default gateway the wireless performance will be limiting factor - I think it won't - so it's more of an appropriate scenario for a case of a p2p communications on the network. The default-gateway-only will be inherently much more stable, I think - because the multicast on the wired side is fast, so the drops on the wireless side will not matter.
>>>
>>> It's probably worth it to change the text into "There is potential for the failing NUD to *contribute* to a longer recovery and possible creation of the locked situation in the case of flash failure - but the exact quantification of the impact in such an environment is a topic of further study".
>>>
>>> And then maybe I could dump the above thought experiment into a separate draft, to see if the folks could contribute to the experiment / maybe someone could run it - and reference it in this item ?
>>>
>>> It seems like an interesting area to dig a bit more in - creating a suitable model and playing with the parameters to see where it breaks seems like a useful exercise to understand how many hosts can there be in a single /64 on WiFi with a "naive" set of access-points.
>>>
>>> Thoughts ?
>>>
>>> --a
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------


From nobody Wed Feb 26 09:32:41 2014
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71ED1A073E for ; Wed, 26 Feb 2014 09:32:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.922
X-Spam-Level: *
X-Spam-Status: No, score=1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHlvfqFigHBz for ; Wed, 26 Feb 2014 09:32:31 -0800 (PST)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 171891A00E8 for ; Wed, 26 Feb 2014 09:32:29 -0800 (PST)
Received: by mail-wg0-f48.google.com with SMTP id b13so1967796wgh.7 for ; Wed, 26 Feb 2014 09:32:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/iLCmCOvolKc4bcNdX85w/2m9CLx0eJVAaxdCz6IDUY=; b=yOtzb8jLFtYstZVpueYa/tXESsgtzvIjdGJ8ugFZIgdeMtYHTp/RD2jttgyi0NDqYp raCkRw3YmREZvQYlOzk5cEeKWDxc082eMXvxgt26lAJCw7jw6hocIlbYPES4MBuZAKr6 87mXibIjxY1uYPt8x3b0LvI90VlKc6cEeLW6oCNFp9bN5KIMwJ/ydugYY4HvqQI7vnPh BwRbl/OFzVMCuWikrWjpKBAGcNeWShIpCC+6ROHbaEo5elbwBD4g0xMhbFxNM/RInRpE Ec7rENRf87kFMkX5MYeAAcvd5VB4Fd8fy01egDaS/9YO247X1nBK2ITp9h8vNvfmM5yP KLYw==
MIME-Version: 1.0
X-Received: by 10.180.24.227 with SMTP id x3mr8972012wif.41.1393435948367; Wed, 26 Feb 2014 09:32:28 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.120.167 with HTTP; Wed, 26 Feb 2014 09:32:28 -0800 (PST)
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F4D2529F3@PUEXCB1B.nanterre.francetelecom.fr>
References: <20140213085149.4433.65554.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4C31E952@PUEXCB1B.nanterre.francetelecom.fr>  <94C682931C08B048B7A8645303FDC9F36F4D2529F3@PUEXCB1B.nanterre.francetelecom.fr>
Date: Wed, 26 Feb 2014 09:32:28 -0800
X-Google-Sender-Auth: p-xDk4vMfEw_E8hU4xLchjsR6Fc
Message-ID: 
Subject: Re: I-D Action: draft-ietf-6man-multicast-addr-arch-update-03.txt
From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= 
To: mohamed.boucadair@orange.com
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/40Qy_BCbdZgZSH84-Aj7XM9zdv0
Cc: "ipv6@ietf.org" 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2014 17:32:34 -0000

Sorry for the delayed response, I've been effectively offline for a
while.

At Fri, 14 Feb 2014 07:59:41 +0100,
 wrote:

> >This point in my original comment doesn't seem to be fully addressed:
> >
> >- In the NEW format of Section 4.2, this sentence may need to be
> >  revisited:
> >
> >      In this case, the last 4
> >      bits of the previously reserved field are interpreted as embedding
> >      the RP interface ID, as specified in this memo.
> >
> >In 03, the corresponding part is
> >
> >   [..] When the
> >   R-bit is set, the last 4 bits of the previously reserved field are
> >   interpreted as embedding the RP interface ID, as specified in this memo.
> >
> >but it doesn't address my concern since the point is "the previously
> >reserved" can be ambiguous.
>
> [Med] But that sentence is almost the same as in RFC3956:
>
> "...the last 4
>    bits of the previously reserved field are interpreted as embedding
>    the RP interface ID, as specified in this memo. "
>
> That text should be interpreted in the context of RFC3956.

I'm not sure if I understand your logic here, but is there any problem
with my suggested text?

      In this case, the last 4 bits of the field that were reserved in
      [RFC3306] are interpreted as embedding the RP interface ID, as
      specified in this memo.

I believe it's still in the context of RFC3956 (RFC3306 was published
before RFC3956, and the original RFC3956 actually refers to RFC3306
already), and yet addresses my point.  This is relatively a minor
point, and I'm not insisting on adopting the suggestion, but I simply
don't see the reason for not doing so.

> >I also noticed this (weak) suggestion wasn't adopted:
> >
> >: Ah, okay.  Maybe it's a distraction, but I'd consider adding a
> >: "TERMINOLOGY" section or something, where we clarify the point (i.e.,
> >: the draft generally follows RFC 5952 to represent IPv6 addresses
> >: except in citation of already published documents).  But I'd leave it
> >: to you.
> >
> >If ignoring it was your intent, that's fine.  I'm pointing it out just
> >in case it's overlooked.
> [Med] This comment was included: see http://tools.ietf.org/html/draft-ietf-6man-multicast-addr-arch-update-03#section-1
>
>    Textual representation of IPv6 addresses included in the RFC updates
>    follows the recommendation in [RFC5952].

Ah, okay, I missed that part.

--
JINMEI, Tatuya


From nobody Wed Feb 26 10:47:43 2014
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B051A015C for ; Wed, 26 Feb 2014 10:47:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.322
X-Spam-Level: ***
X-Spam-Status: No, score=3.322 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MvCPYmECITf for ; Wed, 26 Feb 2014 10:47:36 -0800 (PST)
Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9967D1A01B3 for <6man@ietf.org>; Wed, 26 Feb 2014 10:47:36 -0800 (PST)
Received: by mail-we0-f172.google.com with SMTP id u56so2035574wes.3 for <6man@ietf.org>; Wed, 26 Feb 2014 10:47:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:date:message-id:subject:from:to:cc:content-type;  bh=KDK+vPJuGqWUkLykSLIZx0x2DppcCqrprSiZOVe+67o=; b=nUohHiG4aPK/eNReMwbh/RS3U9P7CttuBlkKQ4miDIClBpGJ58kRYhs2M1HtcFjpZZ 8tPdbDVky9wLz2Tjfdy7UhGuhRGdMxMHEntGYYha3o9eR84IYTLf9IDm/IVJVqIdplcJ 5ODRiieAZmzU2dGP43uplKIFXLVMoPIctPk5X9JAtTj2hoJ05BhrzuY+F3aH4y51nZfe oHZqXQvoXuqXxYvPGIL5hYHEoqEny3fqmUtzF4+iXVazfsyyYpZKZ14aXsL1uGdl32EF nTgB6TDFAADr6nnqN/n2bnmSKgkDUnWTT7Jy69XdwTJNDae8vyw4XEng5UBwtcTW2+o3 B0RQ==
MIME-Version: 1.0
X-Received: by 10.180.188.66 with SMTP id fy2mr9188391wic.45.1393440454910; Wed, 26 Feb 2014 10:47:34 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.120.167 with HTTP; Wed, 26 Feb 2014 10:47:34 -0800 (PST)
Date: Wed, 26 Feb 2014 10:47:34 -0800
X-Google-Sender-Auth: wtqUkbkt8RwB08feeKSofPKJ8OA
Message-ID: 
Subject: quick question on draft-vyncke-6man-mcast-not-efficient
From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= 
To: draft-vyncke-6man-mcast-not-efficient@tools.ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/85a8mtzHLQtRQH908gECIplHtY4
Cc: "6man@ietf.org" <6man@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2014 18:47:38 -0000

I have one quick question on the draft.

In Section 3.5, it states:

   NDP cache needs to be maintained by refreshing the neighbor cache for
   entries which are in the STALE state.  This requires yet another
   Neighbor Solicitation / Neighbor Advertisement round.

What specifically does this mean?  Simply because a node has a
STALE neighbor cache entry doesn't immediately mean an additional
NS/NA exchange.  In fact, RFC 4861 even prohibits it:

      STALE       The neighbor is no longer known to be reachable but
                  until traffic is sent to the neighbor, no attempt
                  should be made to verify its reachability.

If there's actual traffic to/via that neighbor, it *may* involve NS/NA
('may' because it could even be optimized out if the node implements
the optimization for the DELAY state and applies it), but in that case
the main traffic itself would "wake up mobile devices" anyway, so I
don't understand the point of this discussion.

--
JINMEI, Tatuya


From nobody Wed Feb 26 12:02:31 2014
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00361A08BD for ; Wed, 26 Feb 2014 12:02:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B86qGQqiM6hE for ; Wed, 26 Feb 2014 12:02:22 -0800 (PST)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2061A07FF for ; Wed, 26 Feb 2014 12:02:21 -0800 (PST)
Received: from [192.168.10.18] ([78.204.24.4]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s1QK2Cjw029032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Feb 2014 12:02:14 -0800
Message-ID: <530E4844.2010302@acm.org>
Date: Wed, 26 Feb 2014 12:02:12 -0800
From: Erik Nordmark 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Ralph Droms , Ole Troan 
Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast
References: <5305AF13.5060201@acm.org> <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org> <530BCF83.4090500@acm.org>  <530CAC9D.1040105@acm.org> <2CFB5723-A676-4ADD-B555-83752997CFD7@employees.org> <530D10C2.3080208@acm.org> <847BE1A6-1A6F-4265-BF4A-67AD87504EDC@employees.org> <4D7A18D1-70AB-423D-8E61-DD50BBF2CFB5@gmail.com>
In-Reply-To: <4D7A18D1-70AB-423D-8E61-DD50BBF2CFB5@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Sonic-ID: C;QgzQ4SCf4xGR2iGQCY+HFQ== M;ikJv4iCf4xGR2iGQCY+HFQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/h9TVkEkQMajIsgbm5XNB98XnpkU
Cc: Andrew Yourtchenko , 6man WG 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2014 20:02:23 -0000

On 2/26/14 5:44 AM, Ralph Droms wrote:
>
> Or, the ND messages could be relayed to the DHCP server...
Ralph,

To support DHCP relays with off-link servers and handle legacy hosts 
doing DAD, then we need a relay-to-server extension. One way to do that 
would be to relay the ND messages. But we might need some additional 
info with those. At least we'd want a response with "OK" vs. "duplicate" 
from the server, which doesn't exist in today's ND. And we'd want to 
have DUIDs for the legacy hosts to fit in with what the server does - 
might make sense creating the MAC address-based DUIDs on the relay and 
passing them along to the server.

Supporting relays is solvable - but it requires some new protocol 
mechanisms.
>
> The relay could even snoop the assigned addresses (which is already done now [?] for other purposes.
The relay would be required to build "registered NCEs" based on the 
assigned/verified addresses from the server, and use those plus the 
associated MAC addresses in the forwarding plane. (And somehow ensure 
that other routers on the link have the same info.)
>
> So, legacy hosts can be assigned addresses w/o hints while registering hosts send in the hint to indicate address registration.
Yep - just requires code change on the hosts.
>
> ...and DHCP already has tackled the problem of restoring state through leasequery.
But here the state needs to to be distributed differently. The servers 
(plural) and all the routers (which might be all the DHCP relays) need 
to have consistent state. The leasequery mechanism allows a relay to 
rebuild its gleaned state from a server.

Would we be comfortable mandating that all the routers on a link also be 
DHCP relays, so they can use leasequery?
> I don't see how you can support legacy hosts without that. We can't assume that legacy hosts do DHCP address registrations for RFC 4941 temporary addresses when the A flag is set. Clearing the A flag means that some legacy hosts will not work on those links.
> Hosts with no DHCP implementation at all?
Even if they host implementation contains DHCP, the DHC client code 
(like ISC's) doesn't have a way to request specific addresses (but has 
the ability to renew IA_TA addresses already part of a lease).
Unless other DHC client code has very different support, I don't see how 
deployed host code can handle RFC 4941 addresses using DHCP.

> There may be something to learn about the sync protocol from work on DHCP sync.  We thought it was pretty straightforward until we got to the problem of simultaneous updates between different host/server pairs.

For address registration it would be better to look at software like 
Zookeeper which does quorum election. The would outside of the IETF 
isn't about simple active/standby or active/active network elements.

Regards,
    Erik



From nobody Wed Feb 26 12:14:48 2014
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD581A084B for ; Wed, 26 Feb 2014 11:33:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPMcqYeZbcwA for ; Wed, 26 Feb 2014 11:33:11 -0800 (PST)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 101821A01E4 for ; Wed, 26 Feb 2014 11:33:11 -0800 (PST)
Received: from [192.168.10.18] ([78.204.24.4]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s1QJVxQf027115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Feb 2014 11:32:00 -0800
Message-ID: <530E412E.7000500@sonic.net>
Date: Wed, 26 Feb 2014 11:31:58 -0800
From: Erik Nordmark 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Ole Troan , Erik Nordmark 
Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast
References: <5305AF13.5060201@acm.org> <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org> <530BCF83.4090500@acm.org>  <530CAC9D.1040105@acm.org> <2CFB5723-A676-4ADD-B555-83752997CFD7@employees.org> <530D10C2.3080208@acm.org> <847BE1A6-1A6F-4265-BF4A-67AD87504EDC@employees.org>
In-Reply-To: <847BE1A6-1A6F-4265-BF4A-67AD87504EDC@employees.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Sonic-ID: C;tEQDqRyf4xGciyGQCY+HFQ== M;vsmlqRyf4xGciyGQCY+HFQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/mJVYrj6DbI5jHCL3Vb3zmmZfzTk
X-Mailman-Approved-At: Wed, 26 Feb 2014 12:14:42 -0800
Cc: Andrew Yourtchenko , 6man WG 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2014 19:33:17 -0000

On 2/26/14 3:31 AM, Ole Troan wrote:
>
> there is work apparently on failover:
> RFC7031
> draft-ietf-dhc-dhcpv6-failover-design

Looking at those docs, they design seems to focus on address assignment 
using a pair of servers. For instance,

    A subset of available resources (addresses or prefixes) is reserved
    for secondary server use.  This is required for handling a case where
    both servers are able to communicate with clients, but unable to
    communicate with each other.

That is insufficient for address registration, since AR assumes it 
should work unless somebody else has registered the address. Thus this 
would typically require a quorum (2 out of 3, 3 out of 5, etc) so ensure 
that there can be no duplicate registrations when some of the servers 
are down or unreachable.

Thus address registration is subtle different than address assignment, 
and the design center for DHCP is the latter.
(But still investigating what can be done using DHCP.)

    Erik


From nobody Wed Feb 26 12:55:29 2014
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8DC1A0198 for ; Wed, 26 Feb 2014 12:55:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.098
X-Spam-Level: 
X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFNbFNe3_qbl for ; Wed, 26 Feb 2014 12:55:19 -0800 (PST)
Received: from nm36.bullet.mail.ne1.yahoo.com (nm36.bullet.mail.ne1.yahoo.com [98.138.229.29]) by ietfa.amsl.com (Postfix) with ESMTP id E04E71A0213 for ; Wed, 26 Feb 2014 12:55:16 -0800 (PST)
Received: from [127.0.0.1] by nm36.bullet.mail.ne1.yahoo.com with NNFMP; 26 Feb 2014 20:55:15 -0000
Received: from [98.138.100.111] by nm36.bullet.mail.ne1.yahoo.com with NNFMP;  26 Feb 2014 20:52:26 -0000
Received: from [66.196.81.173] by tm100.bullet.mail.ne1.yahoo.com with NNFMP;  26 Feb 2014 20:52:25 -0000
Received: from [98.139.212.195] by tm19.bullet.mail.bf1.yahoo.com with NNFMP;  26 Feb 2014 20:52:25 -0000
Received: from [127.0.0.1] by omp1004.mail.bf1.yahoo.com with NNFMP; 26 Feb 2014 20:52:25 -0000
X-Yahoo-Newman-Property: ymail-4
X-Yahoo-Newman-Id: 811581.18981.bm@omp1004.mail.bf1.yahoo.com
Received: (qmail 98428 invoked by uid 60001); 26 Feb 2014 20:52:25 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024;  t=1393447945; bh=sBb/Z00ORr9sn2hqP8I0pFuK8NdhrrOGy8sm6ZAkWPw=;  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=bao3NMyGOnZnYTqXuR4NtJ3aLwl+0c3RLyKF6ARt2dsbvYiCZb3M87qoIEoW5dbltO/Tqa6saTQu+P5wAnodfMUHSytXRiBxL4eGPzahHI9HuRFKyyOAVUkeHYJdaZJDHpAdUqSUUIyHXhxCEFbgsVWz/UPklfMbtJvXgejyauI=
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=2qIg7uuQN0HQLddjFdmniZNt9g4Nc8jK5xIPpJSP6PTaOac/8xmFdPvJfdgcly8Vp7zTX+jRlNFycgbi0mqtOaEQi/vvWbwfv3G7WMcfMesGhMa3pOguy8kU2GU22HJwq2TPKrveC9lok1SI0N8gK+EgvzqemExwhL9UeoWNQVY=;
X-YMail-OSG: rGQ3aQwVM1kSfl87gArjFJ.iEbeYKYlBTKFhOvEG9lY3KrD aIbn1auvU0C1GJGVZqiTBcmW9EZ8BsfEIcHL_ihChJPf81ZkpsKkEiTJwhD8 _6I091UcZrsEbQk1o_ouPcFhdmGQ85kyCRTrJcwZwHcI0APSNu84pB5csgHs VmqYJBUuAAjW8I5PQjwVNJXwh_H8focFqjajSWxrgtqIusaYryZhefTcmsU4 Vowz4oNf8CuI721t6Edbd.gh1R8V.4xFp8Fasz7ZQc2eB4IKL_DZAc0z9dmk zeX2TRzlBajTtapNVVuxWvZ3r6fCD.83.shEUD_rbnLB5p2Ch4xkIQ9jl3Dz ZdSrDgd61pK9kMzePpabJLay0WJ85yFhdOFrzkopr23dLNwbfEmFUOYHv5RA rw6qk_xOeXQvIFVohPJtLjiRtzI.VyHR4OQ2prta9_7iUIBPeDulyvhL5WHO BGSBGpQk5vILniqHy8fP76Z1dXlgL8a2qLAWiioQfASAOFyFmoFTO1ClffNn Ekz5IF68UdRUEqE8RfkeKMt_sfD0EaSwog6sWAdVzdwzLCKy8f9mOpmmLkND _1R28b4.FQK8HOSshbnEBnxLKPOeuEsReREgBKg--
Received: from [150.101.221.237] by web162205.mail.bf1.yahoo.com via HTTP; Wed, 26 Feb 2014 12:52:25 PST
X-Rocket-MIMEInfo: 002.001, SGkgRXJpaywKCgotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gRnJvbTogRXJpayBOb3JkbWFyayA8bm9yZG1hcmtAYWNtLm9yZz4KPiBUbzogTWFyayBaWlogU21pdGggPG1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU.OyBPbGUgVHJvYW4gPG90cm9hbkBlbXBsb3llZXMub3JnPgo.IENjOiBBbmRyZXcgWW91cnRjaGVua28gPGF5b3VydGNoQGNpc2NvLmNvbT47IDZtYW4gV0cgPGlwdjZAaWV0Zi5vcmc.Cj4gU2VudDogVHVlc2RheSwgMjUgRmVicnVhcnkgMjAxNCAxMDoxMCBQTQo.IFN1YmplY3Q6IFIBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.177.636
References: <5305AF13.5060201@acm.org> <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org> <530BCF83.4090500@acm.org> <1393319543.97599.YahooMailNeo@web162201.mail.bf1.yahoo.com> <530C7A37.2030706@acm.org>
Message-ID: <1393447945.97980.YahooMailNeo@web162205.mail.bf1.yahoo.com>
Date: Wed, 26 Feb 2014 12:52:25 -0800 (PST)
From: Mark ZZZ Smith 
Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast
To: Erik Nordmark , Ole Troan 
In-Reply-To: <530C7A37.2030706@acm.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/LkOzOK4wM1Ec8Nkr5uyUBrVbUy4
Cc: Andrew Yourtchenko , 6man WG 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Feb 2014 20:55:21 -0000

Hi Erik,=0A=0A=0A----- Original Message -----=0A> From: Erik Nordmark =0A> To: Mark ZZZ Smith ; Ole Troan=
 =0A> Cc: Andrew Yourtchenko ; 6m=
an WG =0A> Sent: Tuesday, 25 February 2014 10:10 PM=0A> Subj=
ect: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast=0A> =0A>=
 On 2/25/14 1:12 AM, Mark ZZZ Smith wrote:=0A>> =0A>>  I don't see how we c=
an do this without host changes even for the case =0A> of=0A>>  IA_NA and I=
A_TA DHCP assigned addresses; the hosts would need to remove=0A>>  the code=
 which does the DAD check for DHCP. (And there would be=0A>>  additional DH=
CP protocol changes needed to support CGA and=0A>>  stable-privacy-addresse=
s and any future address assignment scheme.)=0A>>  I think a DAD Proxy is w=
hat you're looking for -=0A>> =0A>>  RFC6957 - "Duplicate Address Detection=
 Proxy."=0A> Mark,=0A> =0A> RFC 6957 is useful for some types of deployment=
.=0A> =0A> But it don't see how it relates to my observation (in response t=
o Ole) =0A> that DHCPv6 doesn't help with different forms of address assign=
ment and =0A> DAD. Even with DAD proxy, or some other form of DAD enhanceme=
nt, we'd =0A> still do address assignment (SLAAC, DHCPv6, stable-private, e=
tc) =0A> separately from DAD.=0A=0AI agree. The DAD proxy is how the DAD is=
sue is dealt with in broadband N:1 / hub-and-spoke etc. link-layer forwardi=
ng models when hosts/CPE are layer 2 isolated from each other, and can only=
 send traffic to other on-link destinations via the default router (perform=
ing the DAD proxy function)=0A=0A>> =0A>>  More broadly though, I think a m=
ethod that supports any forms of multicast =0A> from a host to the other ho=
sts on the link, hair-pinned through the upstream =0A> router(s), would be =
better. It would support DAD operation, and would also =0A> support other m=
ulticasts from hosts, such as Multicast DNS for device (printer) =0A> disco=
very, and SSDP for DLNA server discovery.=0A> You mean instead of hair-pinn=
ing at L2 (through the AP) do the =0A> hair-pinning at L3 (through the rout=
er)?=0A> =0A> Would the router decrement ttl as it forwards those packets?=
=0A> (If not, then I think you are talking about hair-pinning at L2 but =0A=
> placing it in the router.)=0A=0AYes.=A0=0A=0A> Note that L2 hair-pinning =
typically (always?) does split horizon, hence =0A> you'd need to it in the =
devices along the path from the sender to the =0A> router (e.g., the AP) if=
 you want to ensure that all receivers can get a =0A> copy of the packet.=
=0A=0AYes, layer 2 split horizon is preserved. It is the default router tha=
t forwards traffic to all destinations, even those that fall within the pre=
fixes from which the origin host has its addresses.=0A=0A> Hair-pinning can=
 potentially be avoided for L3 - if the router =0A> decrements ttl then it =
would be safer to send the multicast packet out =0A> the input port.=0A>=A0=
=0A=0AThe router would perform standard IPv6 forwarding, including TTL decr=
ement. Although Link-Locals currently won't use their default gateway to re=
ach other Link-Local destinations, if that was changed, I think it is quite=
 legal for a router to forward a link-local packet back onto the same link =
(with a TTL decrement) - RFC4291 only precludes them being forwarded onto a=
 different link.=A0=0A=0A> However, ttl decrements break the protocols that=
 use the ttl=3D255 check =0A> (and ND isn't the only protocol which does th=
is.)=0A>=A0=0A=0AThat is a good point, one I hadn't considered. I'd be inte=
rested to know which non-ND protocols use the TTL=3D255 trick if you know t=
hem off of the top of your head. We might be lucky, the other ones which do=
 use the TTL=3D255 trick might be ones that for security purposes we wouldn=
't want the default router to forward between hosts attached to the same li=
nk anyway.=A0=0A=0AThe use of the TTL=3D255 trick for ND would actually be =
useful for naturally preventing rogue RAs from the hosts - if the default r=
outer forwarded them to other hosts on the link, decrementing the TTL to 25=
4, the receiving hosts should then ignore them.=0A=0ARegards,=0AMark.=0A=0A=
=0A> Regards,=0A> =0A> =A0 =A0 Erik=0A> =0A>>  I've been thinking about thi=
s scenario for quite a while, and it seems =0A> to me that there are fundam=
entally two approaches to this problem.=0A>> =0A>>  The first one involves =
minimal or no changes to the hosts (e.g., an =0A> optional RA PIO for link-=
local flagged as off-link and that is it, as a host =0A> local optimisation=
 instead of ND proxy for link-local addresses), and emulate =0A> functions =
at the upstream router(s) that won't work because of host to host =0A> isol=
ation within the link.=0A>> =0A>>  The other one involves wholesale changes=
 to the hosts, and I think that =0A> would mean fully implementing an IPv6 =
NBMA subnet, perhaps with an RA option to =0A> announce to the hosts that t=
he link is operating in NBMA mode, and the =0A> address(es) of the MARS clu=
ster.=0A>> =0A>>  The NBMA method would be convenient, as all these sorts o=
f =0A> multicast/link-local etc. issues are already dealt with. However, I =
think =0A> wholesale changes to hosts to support it are probably infeasible=
.=0A>> =0A>> =0A>>  Regards,=0A>>  Mark.=0A>> =0A>> =0A>> =0A>> =0A>>> =A0 =
=A0 =A0 Erik=0A>>> =0A>>> =0A>>>  -----------------------------------------=
---------------------------=0A>>>  IETF IPv6 working group mailing list=0A>=
>>  ipv6@ietf.org=0A>>>  Administrative Requests: https://www.ietf.org/mail=
man/listinfo/ipv6=0A>>>  --------------------------------------------------=
------------------=0A>>> =0A> 


From nobody Wed Feb 26 18:06:03 2014
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9BB1A06AB for ; Wed, 26 Feb 2014 18:05:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.274
X-Spam-Level: 
X-Spam-Status: No, score=0.274 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZEMfJnEeoCC for ; Wed, 26 Feb 2014 18:05:55 -0800 (PST)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E6EC31A0359 for <6man@ietf.org>; Wed, 26 Feb 2014 18:05:54 -0800 (PST)
Received: by mail-ie0-f170.google.com with SMTP id y20so1529674ier.29 for <6man@ietf.org>; Wed, 26 Feb 2014 18:05:53 -0800 (PST)
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=OvzgwgSIwmxKBJqzWPALx7vVLeJ3Oord4wbZboZI2hg=; b=n+CioYMnpkpv8Z8qOqg27dgUYi0mJ66G19T/DjMJakJHcTtEz+gRat5E92M+RkhfdC 5T2ZIltSRFuV1947MoziPVqfiSGGC7JwFgAVCT3HPnzS7MGzKQazoHqIdI7SclIG75tY QYeI9ETe6zLj31Se9XLhp7MaJnRNXvq8fRA9nLfTVpWxU+y4meCmf9sUWaZtfKnhdJRk GqmoA5kDnawM/ooGEpOpVHpi1N7BJUOg1Zg21Rdl8Yg+o7H1h4C61Kzn9t5TibkjxdOx vMxQuMi1AIy/nM12P7IoSVO8I/brWbu+bfjOo+TVAQDUgTVNbfPumrTeaA85VPtRPIi/ bk8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=OvzgwgSIwmxKBJqzWPALx7vVLeJ3Oord4wbZboZI2hg=; b=TwWVibjqR4m7LjgQhiZ8VBhkYZYnqpiRbmcesL5nP5FrXrbxyE4KfcUm8lswzJra1d mpzQNCYCQo/M1guX5AcjZqVMmgVeQkP5kkXKe8071/P54nYZMSKgwKJhOQiDv9dkCFao LsFgqXnz+OQB3tqLOGPYlWR4Q25/lLAAzTiQ4pgFlmokwhMv1Y8F89IJpo92EeeAf5P5 F8J/zo18jeWisbAAobNe7sO3Z/WNi4FFqcou3AwWkW9QVfRoDM8WutD6KZBPlHCRkp0O Tx3nRpcx96B+JFiAbbKL45E1nYEnS6O7Y9h91uWsOzJ6tDxwzGXLJ50oeOzGnSOHrep2 O62A==
X-Gm-Message-State: ALoCoQnjN1vcFo9gwc6BuV1ADboMbu5lUnmGfnSf/rOOgHbaKYOkz8ePpx824Rt/2syCYYu5S4VtRiCrS2FL+6W2F1Uh9CxDUf97mk62vnNP1mXiNEHYMscqPxidyXF1vwSnQd35PJlWSS+aNQUxdvSrOLSGQHh7k6efNK4+NTwesdVhHo54IHQTghKnyWaSItcyRPm262wy
X-Received: by 10.43.83.68 with SMTP id af4mr2692819icc.60.1393466753548; Wed, 26 Feb 2014 18:05:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.18.136 with HTTP; Wed, 26 Feb 2014 18:05:33 -0800 (PST)
In-Reply-To: 
References: 
From: Lorenzo Colitti 
Date: Thu, 27 Feb 2014 11:05:33 +0900
Message-ID: 
Subject: Re: quick question on draft-vyncke-6man-mcast-not-efficient
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Content-Type: multipart/alternative; boundary=f46d0447f0feda201804f359c208
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/v7vrxMx_XapWnjumSQuEULBhCr4
Cc: "6man@ietf.org" <6man@ietf.org>, draft-vyncke-6man-mcast-not-efficient@tools.ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Feb 2014 02:05:56 -0000

--f46d0447f0feda201804f359c208
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 27, 2014 at 3:47 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89  wrote:

> If there's actual traffic to/via that neighbor, it *may* involve NS/NA
> ('may' because it could even be optimized out if the node implements
> the optimization for the DELAY state and applies it), but in that case
> the main traffic itself would "wake up mobile devices" anyway, so I
> don't understand the point of this discussion.
>

What he said.

I don't understand what the problem is either.


   1. 1. If it's multicast traffic we're worried about, then this traffic
   is unicast and we shouldn't be worried about it. If the IP to MAC mappin=
g
   has expired from the ND cache, then why did it expire?
      1. If it expired because the router overflowed the ND table (i.e., it
      thought it was keeping too much state and had to throw it away), then
      there's no way to fix that - even address registration won't
help, because
      the amount of state is the same.
      2. If it didn't expire due to state exhaustion, well, implementations
      can fix this problem it by simply *not expiring ND cache entries
when they
      don't need to*.
   2. If it's raw packets and battery impact we're talking about, then...
   you're sending that neighbour unicast packets already, so it's awake and
   using power. The additional traffic caused by one 72-byte unicast packet
   every 30 seconds seems like something that's not worth worrying about
   except in the most remote of corner cases.

If it ain't broke, don't fix it.

--f46d0447f0feda201804f359c208
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
hu, Feb 27, 2014 at 3:47 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@=
wide.ad.jp> wrote:


If there's actual traffic to/via that neighbor, it *may* involve NS/NA<=
br>
('may' because it could even be optimized out if the node implement=
s

the optimization for the DELAY state and applies it), but in that case

the main traffic itself would "wake up mobile devices" anyway, so=
 I

don't understand the point of this discussion.
What he said.

I don't understand w=
hat the problem is either.

  1. 1. If it's =
multicast traffic we're worried about, then this traffic is unicast and=
 we shouldn't be worried about it. If the IP to MAC mapping has expired=
 from the ND cache, then why did it expire?
    2. 


    1. If it expired because the router overflowed the ND table (i.e., it =
thought it was keeping too much state and had to throw it away), then there=
's no way to fix that - even address registration won't help, becau=
se the amount of state is the same.
      2. 


    2. If it didn't expire due to state exhaustion, well, implementations =
can fix this problem it by simply *not expiring ND cache entries when they =
don't need to*.
  2. If it's raw packets and battery impact=
 we're talking about, then... you're sending that neighbour unicast=
 packets already, so it's awake and using power. The additional traffic=
 caused by one 72-byte unicast packet every 30 seconds seems like something=
 that's not worth worrying about except in the most remote of corner ca=
ses.
    3. 


If it ain't broke, don't fix it.
<=
/div>

--f46d0447f0feda201804f359c208--


From nobody Thu Feb 27 08:11:27 2014
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B287C1A0286 for ; Thu, 27 Feb 2014 08:11:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.747
X-Spam-Level: 
X-Spam-Status: No, score=-14.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJAsRb-PcJEB for ; Thu, 27 Feb 2014 08:11:17 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id AE5901A0204 for <6man@ietf.org>; Thu, 27 Feb 2014 08:11:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10539; q=dns/txt; s=iport; t=1393517471; x=1394727071; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rGj1Db7nk4YzvE7rtDXtsmaMtabrsZCXp0mgo2g9Fy8=; b=fyxH9Ixae5jAFpWTwTidEjckYc6+rqYVL98J0z053iFzDU8D5Qi/p9FD 5z8Kr9qH7SbhVAQ+tXEvzSI9m4Z3QkcHlws5v0mONkxka19boxV28Zgx9 xj0dTgvalkrlf6p7AwcCZx9AeSMZGSICWaG1rNfIikUjSgMBZ4xr8mIMW g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlMFADliD1OtJXG+/2dsb2JhbABagkJEgRKDA74IGIEDFnSCJQEBAQQjVhACAQYCEQMBAigDAgICMBQJCAIEAQ0FGYdgjV6cB6EcF41tGj0RB4JugUkEmDiSKoMtgio
X-IronPort-AV: E=Sophos;i="4.97,555,1389744000";  d="scan'208,217";a="306919282"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 27 Feb 2014 16:11:11 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1RGBATW011159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Feb 2014 16:11:10 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.205]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Thu, 27 Feb 2014 10:11:10 -0600
From: "Eric Vyncke (evyncke)" 
To: Lorenzo Colitti , =?utf-8?B?56We5piO6YGU5ZOJ?= 
Subject: Re: quick question on draft-vyncke-6man-mcast-not-efficient
Thread-Topic: quick question on draft-vyncke-6man-mcast-not-efficient
Thread-Index: AQHPMyNE0ZiA5jApG0GrjHOsWHdXHJrIvxmAgABmJQA=
Date: Thu, 27 Feb 2014 16:11:09 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.21.75.73]
Content-Type: multipart/alternative; boundary="_000_CF34A324F17Bevynckeciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/sJuBVAYA13MswxI27C_YdnROISU
Cc: "6man@ietf.org" <6man@ietf.org>, "draft-vyncke-6man-mcast-not-efficient@tools.ietf.org" 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Feb 2014 16:11:25 -0000

--_000_CF34A324F17Bevynckeciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SmluIGFuZCBMb3JlbnpvLA0KDQpUaGFua3MgZm9yIHJlYWRpbmcgdGhlIGRyYWZ0LiBBbmQsIGlu
ZGVlZCB0aGUgb25seSBpc3N1ZSBpcyBzb21lIG1vcmUgdW5pY2FzdCB0cmFmZmljIChhdCBJUCBh
bmQgTUFDIGxheWVyKSBhcyBpbmRpY2F0ZWQgaW4gdGhlIGRyYWZ0LiBCdXQsIHlvdSBhcmUgcmln
aHQsIGl0IGlzIG5lYXJseSBub3RoaW5nIG1vcmUgb24gdGhlIGJhbmR3aWR0aCBhbmQgaXQgaGFz
IG5lYXJseSB6ZXJvIGltcGFjdCBvbiBiYXR0ZXJ5IGxpZmUgPT4gdGhpcyBzZWN0aW9uIHdpbGwg
YmUgcmVtb3ZlZA0KDQpUaGFua3MgYWdhaW4NCg0KLcOpcmljDQoNCkZyb206IExvcmVuem8gQ29s
aXR0aSA8bG9yZW56b0Bnb29nbGUuY29tPG1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20+Pg0KRGF0
ZTogbWVyY3JlZGkgMjYgZsOpdnJpZXIgMjAxNCAxODowNQ0KVG86IOelnuaYjumBlOWTiSA8amlu
bWVpQHdpZGUuYWQuanA8bWFpbHRvOmppbm1laUB3aWRlLmFkLmpwPj4NCkNjOiAiZHJhZnQtdnlu
Y2tlLTZtYW4tbWNhc3Qtbm90LWVmZmljaWVudEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQt
dnluY2tlLTZtYW4tbWNhc3Qtbm90LWVmZmljaWVudEB0b29scy5pZXRmLm9yZz4iIDxkcmFmdC12
eW5ja2UtNm1hbi1tY2FzdC1ub3QtZWZmaWNpZW50QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFm
dC12eW5ja2UtNm1hbi1tY2FzdC1ub3QtZWZmaWNpZW50QHRvb2xzLmlldGYub3JnPj4sICI2bWFu
QGlldGYub3JnPG1haWx0bzo2bWFuQGlldGYub3JnPiIgPDZtYW5AaWV0Zi5vcmc8bWFpbHRvOjZt
YW5AaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IHF1aWNrIHF1ZXN0aW9uIG9uIGRyYWZ0LXZ5bmNr
ZS02bWFuLW1jYXN0LW5vdC1lZmZpY2llbnQNClJlc2VudC1Gcm9tOiA8ZHJhZnQtYWxpYXMtYm91
bmNlc0B0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtYWxpYXMtYm91bmNlc0B0b29scy5pZXRm
Lm9yZz4+DQpSZXNlbnQtVG86IEFuZHJldyBZb3VydGNoZW5rbyA8YXlvdXJ0Y2hAY2lzY28uY29t
PG1haWx0bzpheW91cnRjaEBjaXNjby5jb20+PiwgRXJpYyBBYmVnbm9saSA8ZWxldnlhYmVAY2lz
Y28uY29tPG1haWx0bzplbGV2eWFiZUBjaXNjby5jb20+PiwgRXJpYyBWeW5ja2UgPGV2eW5ja2VA
Y2lzY28uY29tPG1haWx0bzpldnluY2tlQGNpc2NvLmNvbT4+LCA8cHRodWJlcnRAY2lzY28uY29t
PG1haWx0bzpwdGh1YmVydEBjaXNjby5jb20+Pg0KUmVzZW50LURhdGU6IG1lcmNyZWRpIDI2IGbD
qXZyaWVyIDIwMTQgMTg6MDYNCg0KT24gVGh1LCBGZWIgMjcsIDIwMTQgYXQgMzo0NyBBTSwg56We
5piO6YGU5ZOJIDxqaW5tZWlAd2lkZS5hZC5qcDxtYWlsdG86amlubWVpQHdpZGUuYWQuanA+PiB3
cm90ZToNCklmIHRoZXJlJ3MgYWN0dWFsIHRyYWZmaWMgdG8vdmlhIHRoYXQgbmVpZ2hib3IsIGl0
ICptYXkqIGludm9sdmUgTlMvTkENCignbWF5JyBiZWNhdXNlIGl0IGNvdWxkIGV2ZW4gYmUgb3B0
aW1pemVkIG91dCBpZiB0aGUgbm9kZSBpbXBsZW1lbnRzDQp0aGUgb3B0aW1pemF0aW9uIGZvciB0
aGUgREVMQVkgc3RhdGUgYW5kIGFwcGxpZXMgaXQpLCBidXQgaW4gdGhhdCBjYXNlDQp0aGUgbWFp
biB0cmFmZmljIGl0c2VsZiB3b3VsZCAid2FrZSB1cCBtb2JpbGUgZGV2aWNlcyIgYW55d2F5LCBz
byBJDQpkb24ndCB1bmRlcnN0YW5kIHRoZSBwb2ludCBvZiB0aGlzIGRpc2N1c3Npb24uDQoNCldo
YXQgaGUgc2FpZC4NCg0KSSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgdGhlIHByb2JsZW0gaXMgZWl0
aGVyLg0KDQoNCiAgMS4gIDEuIElmIGl0J3MgbXVsdGljYXN0IHRyYWZmaWMgd2UncmUgd29ycmll
ZCBhYm91dCwgdGhlbiB0aGlzIHRyYWZmaWMgaXMgdW5pY2FzdCBhbmQgd2Ugc2hvdWxkbid0IGJl
IHdvcnJpZWQgYWJvdXQgaXQuIElmIHRoZSBJUCB0byBNQUMgbWFwcGluZyBoYXMgZXhwaXJlZCBm
cm9tIHRoZSBORCBjYWNoZSwgdGhlbiB3aHkgZGlkIGl0IGV4cGlyZT8NCiAgICAgKiAgIElmIGl0
IGV4cGlyZWQgYmVjYXVzZSB0aGUgcm91dGVyIG92ZXJmbG93ZWQgdGhlIE5EIHRhYmxlIChpLmUu
LCBpdCB0aG91Z2h0IGl0IHdhcyBrZWVwaW5nIHRvbyBtdWNoIHN0YXRlIGFuZCBoYWQgdG8gdGhy
b3cgaXQgYXdheSksIHRoZW4gdGhlcmUncyBubyB3YXkgdG8gZml4IHRoYXQgLSBldmVuIGFkZHJl
c3MgcmVnaXN0cmF0aW9uIHdvbid0IGhlbHAsIGJlY2F1c2UgdGhlIGFtb3VudCBvZiBzdGF0ZSBp
cyB0aGUgc2FtZS4NCiAgICAgKiAgIElmIGl0IGRpZG4ndCBleHBpcmUgZHVlIHRvIHN0YXRlIGV4
aGF1c3Rpb24sIHdlbGwsIGltcGxlbWVudGF0aW9ucyBjYW4gZml4IHRoaXMgcHJvYmxlbSBpdCBi
eSBzaW1wbHkgKm5vdCBleHBpcmluZyBORCBjYWNoZSBlbnRyaWVzIHdoZW4gdGhleSBkb24ndCBu
ZWVkIHRvKi4NCiAgMi4gIElmIGl0J3MgcmF3IHBhY2tldHMgYW5kIGJhdHRlcnkgaW1wYWN0IHdl
J3JlIHRhbGtpbmcgYWJvdXQsIHRoZW4uLi4geW91J3JlIHNlbmRpbmcgdGhhdCBuZWlnaGJvdXIg
dW5pY2FzdCBwYWNrZXRzIGFscmVhZHksIHNvIGl0J3MgYXdha2UgYW5kIHVzaW5nIHBvd2VyLiBU
aGUgYWRkaXRpb25hbCB0cmFmZmljIGNhdXNlZCBieSBvbmUgNzItYnl0ZSB1bmljYXN0IHBhY2tl
dCBldmVyeSAzMCBzZWNvbmRzIHNlZW1zIGxpa2Ugc29tZXRoaW5nIHRoYXQncyBub3Qgd29ydGgg
d29ycnlpbmcgYWJvdXQgZXhjZXB0IGluIHRoZSBtb3N0IHJlbW90ZSBvZiBjb3JuZXIgY2FzZXMu
DQoNCklmIGl0IGFpbid0IGJyb2tlLCBkb24ndCBmaXggaXQuDQo=

--_000_CF34A324F17Bevynckeciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <9ABEC97107DD3740892576DE9EA8AC68@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+SmluIGFuZCBM
b3JlbnpvLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzIGZvciByZWFkaW5n
IHRoZSBkcmFmdC4gQW5kLCBpbmRlZWQgdGhlIG9ubHkgaXNzdWUgaXMgc29tZSBtb3JlIHVuaWNh
c3QgdHJhZmZpYyAoYXQgSVAgYW5kIE1BQyBsYXllcikgYXMgaW5kaWNhdGVkIGluIHRoZSBkcmFm
dC4gQnV0LCB5b3UgYXJlIHJpZ2h0LCBpdCBpcyBuZWFybHkgbm90aGluZyBtb3JlIG9uIHRoZSBi
YW5kd2lkdGggYW5kIGl0IGhhcyBuZWFybHkgemVybyBpbXBhY3Qgb24gYmF0dGVyeSBsaWZlID0m
Z3Q7IHRoaXMNCiBzZWN0aW9uIHdpbGwgYmUgcmVtb3ZlZDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp
dj4NCjxkaXY+VGhhbmtzIGFnYWluPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4tw6ly
aWM8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJ
T04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRl
eHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBC
T1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVG
VDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlk
OyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0
eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+TG9yZW56byBDb2xpdHRpICZsdDs8
YSBocmVmPSJtYWlsdG86bG9yZW56b0Bnb29nbGUuY29tIj5sb3JlbnpvQGdvb2dsZS5jb208L2E+
Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+bWVy
Y3JlZGkgMjYgZsOpdnJpZXIgMjAxNCAxODowNTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo
dDpib2xkIj5UbzogPC9zcGFuPuelnuaYjumBlOWTiSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmppbm1l
aUB3aWRlLmFkLmpwIj5qaW5tZWlAd2lkZS5hZC5qcDwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9
ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0
LXZ5bmNrZS02bWFuLW1jYXN0LW5vdC1lZmZpY2llbnRAdG9vbHMuaWV0Zi5vcmciPmRyYWZ0LXZ5
bmNrZS02bWFuLW1jYXN0LW5vdC1lZmZpY2llbnRAdG9vbHMuaWV0Zi5vcmc8L2E+JnF1b3Q7ICZs
dDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtdnluY2tlLTZtYW4tbWNhc3Qtbm90LWVmZmljaWVudEB0
b29scy5pZXRmLm9yZyI+ZHJhZnQtdnluY2tlLTZtYW4tbWNhc3Qtbm90LWVmZmljaWVudEB0b29s
cy5pZXRmLm9yZzwvYT4mZ3Q7LA0KICZxdW90OzxhIGhyZWY9Im1haWx0bzo2bWFuQGlldGYub3Jn
Ij42bWFuQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOjZtYW5AaWV0Zi5v
cmciPjZtYW5AaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi
b2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IHF1aWNrIHF1ZXN0aW9uIG9uIGRyYWZ0LXZ5bmNrZS02
bWFuLW1jYXN0LW5vdC1lZmZpY2llbnQ8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s
ZCI+UmVzZW50LUZyb206IDwvc3Bhbj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWFsaWFzLWJv
dW5jZXNAdG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWFsaWFzLWJvdW5jZXNAdG9vbHMuaWV0Zi5vcmc8
L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5SZXNlbnQtVG86IDwv
c3Bhbj5BbmRyZXcgWW91cnRjaGVua28gJmx0OzxhIGhyZWY9Im1haWx0bzpheW91cnRjaEBjaXNj
by5jb20iPmF5b3VydGNoQGNpc2NvLmNvbTwvYT4mZ3Q7LCBFcmljIEFiZWdub2xpICZsdDs8YSBo
cmVmPSJtYWlsdG86ZWxldnlhYmVAY2lzY28uY29tIj5lbGV2eWFiZUBjaXNjby5jb208L2E+Jmd0
OywgRXJpYyBWeW5ja2UgJmx0OzxhIGhyZWY9Im1haWx0bzpldnluY2tlQGNpc2NvLmNvbSI+ZXZ5
bmNrZUBjaXNjby5jb208L2E+Jmd0OywNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnB0aHViZXJ0QGNp
c2NvLmNvbSI+cHRodWJlcnRAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9u
dC13ZWlnaHQ6Ym9sZCI+UmVzZW50LURhdGU6IDwvc3Bhbj5tZXJjcmVkaSAyNiBmw6l2cmllciAy
MDE0IDE4OjA2PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9
Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDog
I2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KPGRp
diBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFRodSwgRmViIDI3LCAyMDE0IGF0IDM6NDcgQU0sIOel
nuaYjumBlOWTiSA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpqaW5tZWlAd2lk
ZS5hZC5qcCIgdGFyZ2V0PSJfYmxhbmsiPmppbm1laUB3aWRlLmFkLmpwPC9hPiZndDs8L3NwYW4+
IHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdp
bjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgi
Pg0KSWYgdGhlcmUncyBhY3R1YWwgdHJhZmZpYyB0by92aWEgdGhhdCBuZWlnaGJvciwgaXQgKm1h
eSogaW52b2x2ZSBOUy9OQTxicj4NCignbWF5JyBiZWNhdXNlIGl0IGNvdWxkIGV2ZW4gYmUgb3B0
aW1pemVkIG91dCBpZiB0aGUgbm9kZSBpbXBsZW1lbnRzPGJyPg0KdGhlIG9wdGltaXphdGlvbiBm
b3IgdGhlIERFTEFZIHN0YXRlIGFuZCBhcHBsaWVzIGl0KSwgYnV0IGluIHRoYXQgY2FzZTxicj4N
CnRoZSBtYWluIHRyYWZmaWMgaXRzZWxmIHdvdWxkICZxdW90O3dha2UgdXAgbW9iaWxlIGRldmlj
ZXMmcXVvdDsgYW55d2F5LCBzbyBJPGJyPg0KZG9uJ3QgdW5kZXJzdGFuZCB0aGUgcG9pbnQgb2Yg
dGhpcyBkaXNjdXNzaW9uLjxicj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8
ZGl2PldoYXQgaGUgc2FpZC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgZG9uJ3Qg
dW5kZXJzdGFuZCB3aGF0IHRoZSBwcm9ibGVtIGlzIGVpdGhlci48L2Rpdj4NCjxkaXY+PGJyPg0K
PC9kaXY+DQo8ZGl2Pg0KPG9sPg0KPGxpPjEuIElmIGl0J3MgbXVsdGljYXN0IHRyYWZmaWMgd2Un
cmUgd29ycmllZCBhYm91dCwgdGhlbiB0aGlzIHRyYWZmaWMgaXMgdW5pY2FzdCBhbmQgd2Ugc2hv
dWxkbid0IGJlIHdvcnJpZWQgYWJvdXQgaXQuIElmIHRoZSBJUCB0byBNQUMgbWFwcGluZyBoYXMg
ZXhwaXJlZCBmcm9tIHRoZSBORCBjYWNoZSwgdGhlbiB3aHkgZGlkIGl0IGV4cGlyZT8NCjxvbD4N
CjxsaT5JZiBpdCBleHBpcmVkIGJlY2F1c2UgdGhlIHJvdXRlciBvdmVyZmxvd2VkIHRoZSBORCB0
YWJsZSAoaS5lLiwgaXQgdGhvdWdodCBpdCB3YXMga2VlcGluZyB0b28gbXVjaCBzdGF0ZSBhbmQg
aGFkIHRvIHRocm93IGl0IGF3YXkpLCB0aGVuIHRoZXJlJ3Mgbm8gd2F5IHRvIGZpeCB0aGF0IC0g
ZXZlbiBhZGRyZXNzIHJlZ2lzdHJhdGlvbiB3b24ndCBoZWxwLCBiZWNhdXNlIHRoZSBhbW91bnQg
b2Ygc3RhdGUgaXMgdGhlIHNhbWUuDQo8L2xpPjxsaT5JZiBpdCBkaWRuJ3QgZXhwaXJlIGR1ZSB0
byBzdGF0ZSBleGhhdXN0aW9uLCB3ZWxsLCBpbXBsZW1lbnRhdGlvbnMgY2FuIGZpeCB0aGlzIHBy
b2JsZW0gaXQgYnkgc2ltcGx5ICpub3QgZXhwaXJpbmcgTkQgY2FjaGUgZW50cmllcyB3aGVuIHRo
ZXkgZG9uJ3QgbmVlZCB0byouPC9saT48L29sPg0KPC9saT48bGk+SWYgaXQncyByYXcgcGFja2V0
cyBhbmQgYmF0dGVyeSBpbXBhY3Qgd2UncmUgdGFsa2luZyBhYm91dCwgdGhlbi4uLiB5b3UncmUg
c2VuZGluZyB0aGF0IG5laWdoYm91ciB1bmljYXN0IHBhY2tldHMgYWxyZWFkeSwgc28gaXQncyBh
d2FrZSBhbmQgdXNpbmcgcG93ZXIuIFRoZSBhZGRpdGlvbmFsIHRyYWZmaWMgY2F1c2VkIGJ5IG9u
ZSA3Mi1ieXRlIHVuaWNhc3QgcGFja2V0IGV2ZXJ5IDMwIHNlY29uZHMgc2VlbXMgbGlrZSBzb21l
dGhpbmcgdGhhdCdzDQogbm90IHdvcnRoIHdvcnJ5aW5nIGFib3V0IGV4Y2VwdCBpbiB0aGUgbW9z
dCByZW1vdGUgb2YgY29ybmVyIGNhc2VzLiA8L2xpPjwvb2w+DQo8L2Rpdj4NCjxkaXY+SWYgaXQg
YWluJ3QgYnJva2UsIGRvbid0IGZpeCBpdC48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+
DQo=

--_000_CF34A324F17Bevynckeciscocom_--


From nobody Thu Feb 27 10:28:34 2014
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2EF81A043A for ; Thu, 27 Feb 2014 10:28:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.922
X-Spam-Level: *
X-Spam-Status: No, score=1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dz6NbJMUUVxy for ; Thu, 27 Feb 2014 10:28:28 -0800 (PST)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A8F0C1A042B for ; Thu, 27 Feb 2014 10:28:25 -0800 (PST)
Received: by mail-wi0-f172.google.com with SMTP id r20so1055246wiv.11 for ; Thu, 27 Feb 2014 10:28:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=c533hF2F8sYsWmrDlV4nnwgIk9Je8CYMnFMhUQMu6i0=; b=Dr7hFCi06x3khAtTinHTbDoPDYVBB1AxJS6H6cCGysqQSbGm1QDfd2PuCNReIuz/GI YZ8nNDBXisPt5Ukpjso9FSmHCjtv5aHC6JXxEYP4JY8F10M8nRxcLASnrsm8wSH8CH6S bqbHAbebOGimnPGqfkQhT2Mh79ylt7HLEu2mq28JqWDnzLX6oFFmRCFgkwqdSv83nDt/ DoWCLyvNaZYqVWHfjUwH8X2C++B3AXTTIKvQVrtTDB236B/pH75EUU9bvkR/VMrgogQ9 G9t69dpejoaaRZCQc7A7j9JB7DEMaHeKXGi7v7XPw1jAPgXMaks8NWb81DJhc0XygLOX 7VEQ==
MIME-Version: 1.0
X-Received: by 10.194.219.132 with SMTP id po4mr9369555wjc.7.1393525703644; Thu, 27 Feb 2014 10:28:23 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.120.167 with HTTP; Thu, 27 Feb 2014 10:28:23 -0800 (PST)
In-Reply-To: <52FF115C.30001@acm.org>
References: <20140214235734.2509.63069.idtracker@ietfa.amsl.com> <52FF115C.30001@acm.org>
Date: Thu, 27 Feb 2014 10:28:23 -0800
X-Google-Sender-Auth: -vCDy4NjPk-1-WFsyL7AbFLkZB8
Message-ID: 
Subject: Re: New Version Notification for draft-chakrabarti-nordmark-6man-efficient-nd-05.txt
From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= 
To: Erik Nordmark 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/_AYJ0PvT9BspuSjA9YiRocQXFZA
Cc: IETF IPv6 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Feb 2014 18:28:30 -0000

At Fri, 14 Feb 2014 23:03:56 -0800,
Erik Nordmark  wrote:

> Samita has already outlined some of the changes we have been making
> based on the feedback from the list.

Was this point addressed in 05?

>> Clarify bootstrapping and DAD for link-local or not How to inform duplicate address detection during link-local address formation

Section 11 talks about boot strapping and the formation of a
link-local address, but it doesn't talk about DAD for the LL address.

Section 5 has this bullet:

   o  Address Resolution and DAD uses the registered addresses instead
      of multicast Neighbor Solicitation messages for non-link-local
      IPv6 addresses.

which seems to suggest DAD is used for link-local addresses, but it's
not really clear (and this is not an addition to 05).

Assuming the intent is to perform DAD for the link-local address, I
suggest Section 11 explains that explicitly.  It would also be better
if that point is clarified in Section 8.  And, this point of Section 2
may also have to be updated:

      Remove the use of multicast for DAD and Address Resolution (no
      multicast NS messages), and remove periodic multicast RAs.  Some

so it's clear that DAD is still needed for link-local addresses.

--
JINMEI, Tatuya


From nobody Thu Feb 27 11:14:00 2014
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D231A0639 for ; Thu, 27 Feb 2014 11:13:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIhzk73Ldrl0 for ; Thu, 27 Feb 2014 11:13:57 -0800 (PST)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id ACF941A0584 for ; Thu, 27 Feb 2014 11:13:55 -0800 (PST)
Received: from [192.168.10.18] ([78.204.24.4]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s1RJCmiE003092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 27 Feb 2014 11:12:49 -0800
Message-ID: <530F8E33.2080109@acm.org>
Date: Thu, 27 Feb 2014 20:12:51 +0100
From: Erik Nordmark 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Mark ZZZ Smith , Erik Nordmark , Ole Troan 
Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast
References: <5305AF13.5060201@acm.org> <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org> <530BCF83.4090500@acm.org> <1393319543.97599.YahooMailNeo@web162201.mail.bf1.yahoo.com> <530C7A37.2030706@acm.org> <1393447945.97980.YahooMailNeo@web162205.mail.bf1.yahoo.com>
In-Reply-To: <1393447945.97980.YahooMailNeo@web162205.mail.bf1.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Sonic-ID: C;YhJJJeOf4xGvE7RWCY+HFQ== M;kOjpJeOf4xGvE7RWCY+HFQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/qdjR8IiPZV7OZeHheN7x2BlmbK8
Cc: Andrew Yourtchenko , 6man WG 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Feb 2014 19:13:58 -0000

On 2/26/14 9:52 PM, Mark ZZZ Smith wrote:
> The router would perform standard IPv6 forwarding, including TTL 
> decrement. Although Link-Locals currently won't use their default 
> gateway to reach other Link-Local destinations, if that was changed, I 
> think it is quite legal for a router to forward a link-local packet 
> back onto the same link (with a TTL decrement) - RFC4291 only 
> precludes them being forwarded onto a different link. 
That is correct - link locals can be forwarded out the same link.
I don't know if that is always a good idea for multicast packets - but 
if the router received the L3 multicast packet as a L2 unicast then it 
would make lots of sense to forward it back out on the link.
>> However, ttl decrements break the protocols that use the ttl=255 check
>> (and ND isn't the only protocol which does this.)
>>   
> That is a good point, one I hadn't considered. I'd be interested to know which non-ND protocols use the TTL=255 trick if you know them off of the top of your head. We might be lucky, the other ones which do use the TTL=255 trick might be ones that for security purposes we wouldn't want the default router to forward between hosts attached to the same link anyway.
I haven't tried to compile a list.
I know that routing protocols and VRRP does this (which is a reason why 
a "send link-locals to default router" should not be applied to the 
routers themselves.)

It doesn't look like mDNS uses it according to the RFC. It would be good 
to check this though.

>
> The use of the TTL=255 trick for ND would actually be useful for naturally preventing rogue RAs from the hosts - if the default router forwarded them to other hosts on the link, decrementing the TTL to 254, the receiving hosts should then ignore them.
Yes, for RAs it would help.
But if the hosts still send multicast NSs (e.g., for link-local 
targets), then the ttl decrement ensures that they will never get a 
response.

    Erik


From nobody Thu Feb 27 13:08:45 2014
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90BAC1A0698 for ; Thu, 27 Feb 2014 13:08:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.935
X-Spam-Level: 
X-Spam-Status: No, score=-0.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hG8KnIB350mS for ; Thu, 27 Feb 2014 13:08:37 -0800 (PST)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 332891A06A2 for ; Thu, 27 Feb 2014 13:08:37 -0800 (PST)
Received: from [192.168.10.18] ([78.204.24.4]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s1RL8Sln011831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 27 Feb 2014 13:08:30 -0800
Message-ID: <530FA94B.3050802@acm.org>
Date: Thu, 27 Feb 2014 22:08:27 +0100
From: Erik Nordmark 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Subject: Re: New Version Notification for draft-chakrabarti-nordmark-6man-efficient-nd-05.txt
References: <20140214235734.2509.63069.idtracker@ietfa.amsl.com>	<52FF115C.30001@acm.org> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Sonic-ID: C;xGO3TfOf4xGkwrRWCY+HFQ== M;lIPGTvOf4xGkwrRWCY+HFQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/DcQSVoEcFNnXbEovF4lkWtUzKdg
Cc: IETF IPv6 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Feb 2014 21:08:39 -0000

Jinmei,

thanks for reviewing the updated draft.

On 2/27/14 7:28 PM, 神明é”哉 wrote:
> At Fri, 14 Feb 2014 23:03:56 -0800,
> Erik Nordmark  wrote:
>
>> Samita has already outlined some of the changes we have been making
>> based on the feedback from the list.
> Was this point addressed in 05?
>
>>> Clarify bootstrapping and DAD for link-local or not How to inform duplicate address detection during link-local address formation
Not very well it seems. We discovered shortly before the draft cutoff 
that the 6lowpan-nd approach to handling link-locals doesn't make any 
sense in this broader applicability.
Hence we added how to handle link-locals to the open issues section.

But we seemed to not have edited the rest of the draft correctly around 
DAD, including the bootstrapping section.
As the draft currently stands DAD for link-locals is (or "can be" given 
the lack of editorial clarity) replaced by NS/ARO. But address 
resolution for link-local targets needs to be done for using multicast NS.

One of the discussion on list is how to avoid the latter, with 
suggestions to add the ability to have RAs state that link-locals should 
be sent to routers. That might make sense in some deployments (when 
hosts do not depend on protocols with have a ttl=255 check).

    Erik

>>> Section 11 talks about boot strapping and the formation of a
>>> link-local address, but it doesn't talk about DAD for the LL address.
>>>
>>> Section 5 has this bullet:
>>>
>>>     o  Address Resolution and DAD uses the registered addresses instead
>>>        of multicast Neighbor Solicitation messages for non-link-local
>>>        IPv6 addresses.
>>>
>>> which seems to suggest DAD is used for link-local addresses, but it's
>>> not really clear (and this is not an addition to 05).
>>>
>>> Assuming the intent is to perform DAD for the link-local address, I
>>> suggest Section 11 explains that explicitly.  It would also be better
>>> if that point is clarified in Section 8.  And, this point of Section 2
>>> may also have to be updated:
>>>
>>>        Remove the use of multicast for DAD and Address Resolution (no
>>>        multicast NS messages), and remove periodic multicast RAs.  Some
>>>
>>> so it's clear that DAD is still needed for link-local addresses.
>>>
>>> --
>>> JINMEI, Tatuya
>>>


From nobody Fri Feb 28 07:26:38 2014
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D941A1A02DD for ; Fri, 28 Feb 2014 07:26:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.748
X-Spam-Level: 
X-Spam-Status: No, score=-7.748 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, J_BACKHAIR_32=1, J_CHICKENPOX_35=0.6, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTAbDOgp3mYZ for ; Fri, 28 Feb 2014 07:26:30 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id A1A141A02FD for ; Fri, 28 Feb 2014 07:26:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32214; q=dns/txt; s=iport; t=1393601188; x=1394810788; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=Rb2leLy7gcL+EUYpJfUnarQSAr7oEe/Byt131zq6rrI=; b=mrQTB1MJQOmlIUMuMOFCINVwjT5f12cwvmaeoR6PeogeyT6Es6EyNfop ZUBPfYGtLyDY7i/kh00meoen65oULmqyX27IC/q02pkY7Za/6v+iy4piO Zz1P0DqLQng2VMV5QGuEHx/CsFLC/F9HEWO0xTmpsWz3tRE+QzNo8Q1M7 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqIIAOSpEFOtJXG8/2dsb2JhbABZgwY7V6g2BJhlgRQWdIIlAQEBAgEBGgEMEQIrAgkCBwULCxIGFRlJDgYOHgWHUwgNyz0XjW0QAQMGSQUHCoQtBJRPijWLYYMugWcBBAIZBB4
X-IronPort-AV: E=Sophos;i="4.97,562,1389744000"; d="scan'208";a="23968434"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-6.cisco.com with ESMTP; 28 Feb 2014 15:26:26 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1SFQQkg013896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Feb 2014 15:26:26 GMT
Received: from [10.61.221.73] (10.61.221.73) by xhc-rcd-x10.cisco.com (173.37.183.84) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 28 Feb 2014 09:26:24 -0600
Date: Fri, 28 Feb 2014 16:25:51 +0100
From: Andrew Yourtchenko 
X-X-Sender: ayourtch@ayourtch-mac
To: Erik Nordmark 
Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast
In-Reply-To: <530C85A6.5080404@acm.org>
Message-ID: 
References: <5305AF13.5060201@acm.org>  <530C85A6.5080404@acm.org>
User-Agent: Alpine 2.00 (OSX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="US-ASCII"
X-Originating-IP: [10.61.221.73]
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/jiB0QDvIzsChyz7wn5ODRSo9zEk
Cc: IETF IPv6 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Feb 2014 15:26:35 -0000

On Tue, 25 Feb 2014, Erik Nordmark wrote:

> On 2/20/14 8:56 AM, Andrew Yourtchenko wrote:
>> 
>> Yeah, it's a very useful optimization to consider, we discussed it I think 
>> alread. The reason I did not include it yet, was to go over the tradeoffs 
>> without the pressure of the submission deadline being a few hours away :)
>> 
>> 1) from the efficiency standpoint this approach is fantastic for the wired 
>> and for the wireless (the implementations that do the mcast->ucast 
>> conversion over the air the win is a bit less, but nonetheless there is a 
>> win since we send only one packet on the wired side instead of many and 
>> save the CPU on the gateway).
>> 
>> 2) This adds an instantaneous behavior change into the network at the peak 
>> load conditions - so if that code path has a problem, this creates 
>> hard-to-debug situation.
>> 
>> 3) There are a few trickier scenarios with L3 roaming (hosts arriving from 
>> other subnets onto the same AP) and that AP having a single 802.11 group 
>> encryption key, which this behavior might make easier to accidentally have 
>> broken.
> I don't quite understand concern #3 (and #2). Since the routers doesn't know 
> whether hosts rely on unsolicited multicast RAs, the multicast RAs must 
> function. Thus adding the flash crowd optimization to multicast solicited RAs 
> wouldn't be anything new or different - it would merely appear in one 
> additional case.

My worry is more about the humans than the hosts :-)

char *foo = NULL;
if(unlikely(event)) {
   // Almost never happens
   *foo = 'x';
} else {
   // Almost always happens
}

Is a strawman bug which will be harder to catch just because it is 
triggered in rare circumstances.

That said, since the router/wireless infra will have to ratelimit ingress 
RSs anyway, they might as well send a multicast RA at that point.

>>> 
>>> In section 4.3 there are two suggestions: MLD snooping and L2 unicast or 
>>> L3 multicast packets. I think there are some operational concerns around 
>>> MLD snooping - I hope others can fill in some information in that space 
>>> since I don't know the issues.
>>> (Editorially it would be clearer if those two are separate sub-sections.)
>>> 
>>> The multicast-over-unicast refers to SAVI as a way to collect the state, 
>>> but it doesn't specify where you see that state used. Presumably for DAD 
>>> (and NS in general unless you also do section 4.7)? But SAVI doesn't claim 
>>> to have all addresses since it is concerned with conflicts. Thus a host 
>>> can exist and be silent - but DAD would still expect to reach it. Or a 
>>> host could have moved to a different port and SAVI having stale state - 
>>> yet DAD should work. My point is that the details of how the state is 1) 
>>> maintained and 2) used to forward packets are key to analyzing how the 
>>> neighbor discovery functionality and robustness would be affected by this 
>>> idea.
>> 
>> The hosts that are "quiet" are indeed a problem. However, I think it might 
>> be very OS-specific - the today's smartphones are anything but quiet :-)
>> So I think this will be much more of an issue for some special-purpose 
>> devices, which are also predominantly servers.

> I guess my first question was how this would work when there is no SAVI-like 
> state for an address. (In that case you don't have a unicast address to which 
> you can send the packet.) Would you multicast or drop?

My instinct is to say "multicast" since that will provide the 
backwards-compatible recovery.

But I think it can be more nuanced. Piggybacking on the resolicit idea 
from this thread below, if the gateway keeps track of the counts of 
"vanilla" and "resolicit-capable" hosts over time, it might be able to 
make an informed decision. If it saw a legacy host within a certain 
timeframe in the past (I am assuming that it would always see the router 
solicitation), then it would err on the side of multicasting, else if 
there are no vanilla hosts and the router did not clean up any of the 
neighbors within a router lifetime, there's no point to multicast.


>> I think the smart-meter type of device would be in this category. But to 
>> access those, the remote party will need to know their address... so, if a 
>> device does some sort of service registration upon boot-up, then it will 
>> not be a quiet device anymore.
> But the service registration could have happened when the device was first 
> installed - I don't think that is likely to happen each time the device wakes 
> up.

True, it actually should *not* happen.

So the failure scenario is:

1) the host does behave according to today's specs
2) the host is providing a service for the remote hosts
3) the router has deleted the neighbor entry for that host
4) the host does not call home to recreate this entry
5) the router has decided not to multicast the NS to resolve an address this host

It seems like a robust implementation can fairly easily avoid the (3) and 
(4) - whereas a router can try to be more conservative about (5).

>> I haven't seen this failure in the "consumer portable devices" networks 
>> that I ran - so this is purely a mental construct.

> Yes, but IPv6 needs to work for other sleepy devices. We want whatever 
> improvements we do to the standards in this space to be useful for the next 
> 20 years or so. (Products, whether end devices or routers/switches can 
> operate on shorter time scales and with more limited applicability than the 
> core standards.)

Indeed. Another aspect is to try to make improvements in such a way that 
they are not required on two sides at once to be useful - this should 
help with their adoption.

>
>> 
>> I do agree that there are limitations - but I think it is very important to 
>> collect the data about the scope of these limitations, to keep a balanced 
>> approach.
>> 
>> The data I have as of today based on 5-6 networks with 10-20K hosts says it 
>> is quite minimal. But I reserve the right to be wrong and thus would be 
>> very interested to hear about other live networks where it is different.
>> 
>> (side note: if these sleepy hosts are quiet and are concerned that their 
>> address be known, they might consider to use DHCPv6 as well).

> Using DHCPv6 doesn't reduce multicast (neither for address resolution nor for 
> dad). One could change DHCP to record the link-layer addresses so that the 
> routers would ask the DHCP servers for the link-layer addresses, but that 
> seems like a lot of change.
>
> Also, see my response to Ole on the other ways that the DHCPv6 we currently 
> have doesn't help solve the problems at hand. [I see others brought up the 
> same concerns around DHCPv6 on the list.]

yeah. I won't fork the discussion and will see if I can contribute 
anything within that thread :-)

>
>> 
>>> 
>>> I section 4.4 the document refers to proxy but without specifying which of 
>>> the different proxy approaches you have in mind.
>>> There is the proxy ND RFC, and there is the DAD proxy internet-draft in 
>>> 6man. Are you referring to one of those, or some slightly different form 
>>> of proxy? (For example, ND proxy would respond with the LLA of the 
>>> router/AP, but that might result in host movement looking like a duplicate 
>>> address - again depends on the details.)
>> 
>> I don't know the spec. I saw it implemented in a product, where two 
>> attached clients A and B during the ND saw the packet sequences that were 
>> close enough to the ND spec to achieve identical practical result and be 
>> compliant to the letter of it, yet allowed to perform the process more 
>> optimally from the broader perspective.
>> 
>> Arguably this kind of behavior would not require its own spec ?

> Yes, because it depending on the details it might break SeND and other ND
> options, or it might only be robust and useful in very limited applicability 
> for instance in specific topologies (such as a single wireless controller).

That'd be a bug for that implementation to fix.

Arguably having a spec in this particular case might do more harm that 
good - if there is a bug in the spec which an implementation follows, then 
first a spec has to be fixed, then the code has to be fixed.

>
>>> I don't have any issue with removing the somewhat arbitrary 9000 second 
>>> max AdvDefaultLifetime in section 5.1. However, the tradeoff for what 
>>> default lifetime to use in section 4.5 needs to take into account one 
>>> additional factor.
>>> The default lifetime serves to garbage collect entries from the default 
>>> router list should a router silently disappear. Thus for links that do not 
>>> have a fixed (set of) link-local address(es) for the router(s), having a 
>>> high default lifetime means that after a failure the hosts would have one 
>>> entry in the default router list which us unreachable - until that high 
>>> lifetime expires. I don't know if there has been a study on the 
>>> performance impact of that would have on the hosts e.g., how often they 
>>> would re-probe the default router.
>> 
>> This is indeed a useful consideration that is worth noting in a doc that 
>> would be removing the 9000 seconds max limit. Mind if sketch a -00 on this 
>> matter and send you the possible text ?
> That would be excellent.

Ok, I'll sketch it today/on weekend and send unicast.

>
>>> Section 4.6 has the same concern. But 4.5 and 4.6  makes lots of sense 
>>> e.g., in a VRRP deployment where the link-local address of the virtual 
>>> default router would always be the same. Ditto for networks with a single 
>>> point of failure single router at a fixed address (e.g., if the router is 
>>> always at fe80::1 or some other fixed address.) Thus I think we should 
>>> recommend 4.5 and 4.6 that within that applicability. Added benefit is 
>>> that the routers control it, hence the operator of the network can set the 
>>> values higher for VRRP or single router cases.
>> 
>> I totally agree! We probably might have a series of documents for different 
>> types of use cases - this could be very helpful for the folks deploying 
>> them. We could turn this doc into a "large-scale high-density WiFi 
>> (stadiums, exhibitions, campuses, etc.)" and then have couple of others 
>> describing other types of deployments. Let's discuss this in London ?
> Yep.

>>> In think it would be good to separate out the second half of section 4.7 
>>> (blocking link-locals) into a separate section, since it is quite 
>>> different than clearing the on-link bit. That idea has significant 
>>> implications since it changes the IP subnet model (RFC 4903 talks about 
>>> this.) I not saying that we shouldn't consider this, but I do think it 
>>> would fall in a very different category than the other ideas in this 
>>> draft. Might even be best to have a separate draft on this radical idea so 
>>> it can be explored fully.
>> 
>> I thought RFC5942 was clarifying this (by the way I need to reference it).
> 5942 re-states the intent of 4861 with more detail. But doesn't change the 
> above semantics. (It does remove these two bullets from on-link:
>       *  a Neighbor Advertisement (NA) message is received for the
>          (target) address, or
>       *  any Neighbor Discovery message is received from the address.
> )
>
> The only case I know of where "blocking link-locals" is part of our standards 
> is for multi-link subnets, for instance in 6lowpan. But in that case it was 
> part of the architecture from the start. The issue we have with the general 
> ND evolution is that we need to support the existing assumptions, and many of 
> those assumptions come from IPv4. For instance, the use and semantics of an 
> IPv4 link-local multicast has been carried to IPv6 link-locals.
>
> Removing that will cause some breakage.

Forward-referencing to [*] below.

>> 
>> My thought process was as follows: suppose we have 9000 people, each with a 
>> smartphone, wandering inside a large building or on campus. We want to 
>> limit the broadcast domains. So we will split these 9000 hosts into 256
>> subnets, each with 35-36 hosts. Those are small enough to be close to what 
>> is a typical "small network" so everything will be fine, and the protocols 
>> which do use link-local addresses will actually be able to function.
>> 
>> Good ? Seems so, but, there are problems with this approach:
>> 
>> 1) "Lobby ambassador" problem: everyone arrives through the same entrance, 
>> and turns on their portable device there. Therefore, the assignment of a 
>> host to the subnet must happen there, not based on physical location, but 
>> on some loadbalancing algorithm. I have 256 subnets, so e.g. for 
>> predictability we can use a first byte of a hash of the host's mac address.
>> 
>> 2) I need to span those 256 vlans across the entire venue, and ensure I 
>> place each of the hosts into the correct VLAN on each AP. A typical network 
>> of such a scale will have about 300 APs. I still need to send RAs within 
>> each vlan. I need to ensure that the hosts do not receive the "wrong" RAs. 
>> (and remember, there is not really a way in a naive 802.11 imlementation to 
>> do "selective" multicast).
>> 
>> 3) I have people that are able to see each other using multicast 
>> advertisements, but what relation do they have to each other ? Equality of 
>> the first byte of the hash of their mac address. Not very useful.
>> 
>> So I conclude, that while splitting the whole crowd into smaller subnets 
>> somewhat takes care of the floods at the expense of additional complexity, 
>> the resulting "working" link-local multicast protocols do not really make 
>> any sense - because the partition of the network does not have any other 
>> logic than pure loadbalancing.
> I agree with all that.
>
> For those types of deployments having /127 subnets (plus DHCPv6 PD if someone 
> wants a personal area network behind their phone) makes a lot of sense.
>
> But my issue is that the goals we are trying to achieve are more general than 
> the stadium (or broadband subscriber) use case.
>

Agreed - though I think it might make sense to more explictly document the 
use case and see what applies still ?

e.g.: say we have sensors on a factory floor. Those sensibly will sit on a 
different SSID compared to all the chatty smartphones worn by the workers; 
and given they will be much more "well-behaved", we may not need to be as 
aggressive in suppressing the traffic between the hosts.

Given we are concerned about their energy consumption, most probably the 
direct access to them will be restricted (else one can just ping -f and 
drain the battery) - so that traffic will be quite controlled.

This is a wildly different use case from a high-density BYOD where we 
essentially have a swarm of almost hostile devices outside of our 
control right in the middle of the network.


>> Of course, I need to disclaim: doing this in the home network with one AP 
>> and < 100 devices all belonging to a single person is not useful at all.
>> 
>> Doing this in a network with 9000 devices belonging to different people is 
>> the thing that made the most sense.
> Agreed.
>> 
>> Now that we've cut off all the services, we need to figure out how to bring 
>> them back... And I think the further mental construct here that would be 
>> useful is to consider this as a giant homenet with a lot of guests. Thus, I 
>> think from the services discovery standpoint, the products of the DNS-SD 
>> workgroup will be very beneficial here.

> I don't think such an approach (first break it, then get folks to fix 
> whatever broke whether that means fixing an IETF standard, some common 
> implementation, or various to us unknown and proprietary approaches makes 
> sense for a retrofit.

[*]

Talking specifically mDNS, it breaks itself as we increase the # of 
hosts - whether we keep the multicast on or not - we just get to pick the 
way it breaks:

1) we keep the multicast - so every phone gets the 10000s of 
advertisements, can not make any use of them anyway, only drains the 
battery. (from my experiments, the # of services usable within the UI is 
limited)

2) we get rid of the multicast - and break the discovery upfront in a 
predictable way, declaring it within the AUP for the network.

(Aside: I did not mention it in the doc because I wanted to keep it 
focused on the ND, but in the high-density environments I specifically 
block udp/5353 multicast in its entirety. This does not have to be this 
way, and grouping the hosts into "broadcast domains" based on some 
criterion might be a different approach, but it's nothing implements 
this, to the best of my knowledge).

>
> Only makes sense for a greenfield deployment where there are no assumptions 
> that existing protocols and code continue to work.

Above, we are discussing the use cases different from HD WiFi that do not 
exist today. I count those as green field.

>> 
>>> 
>>> 4.8 seems to conflate the address assignment with DAD. Just because we 
>>> might want to centralize the DAD checks doesn't imply that we want to 
>>> remove the ability for the host to pick its own privacy enhanced 
>>> interface-IDs to form its addresses.
>>> From a deployment perspective DHCPv6 is available for address assignment, 
>>> but don't think we want to require that for WiFi or other links which have 
>>> packet loss.
>> 
>> This is more of a fallback scenario for those who want a 100% guarantee of 
>> address uniqueness in the network - using the existing mechanism.

> But RFC 3315 doesn't guarantee uniqueness, which is why the host needs to do 
> perform DAD in addition.

I need to correct myself. "Those who want a bigger guarantee".

No mechanism gives a 100% guarantee. We asymptotically approach 100% to 
varying degrees.

>> 
>> Also as a trigger for another small discussion:
>> 
>> I think it's worth modeling the real-world experience in the networks with 
>> varying packet loss to see at which point it stops being usable, and go 
>> from there.
>> 
>> The classic IETF "Built-in hotel WiFi" topic: is it worth being extra-sure 
>> that DAD works in that scenario ? Or is it worth fixing the connectivity by 
>> bringing the loss down to acceptable level ? At how many retransmits do we 
>> declare a failure ? Could we then explore a similar approach to make the 
>> DAD more robust instead - keeping in mind the probability of failure should 
>> be quite low ?
>> 
>> This will be a good robustness improvement for the hosts that will 
>> immediately benefit them.

> If we want a DAD probe mechanism that is more robust to failure then I think 
> we should just reuse the techniques in ACD (RFC 5227) which performs ongoing 
> conflict detection. However, that results in or broadcast/multicast messages!

For the 802.11 case we can have a reasonable assurance that there is no 
duplication of the MAC address (else a bunch of L2 stuff would have been 
broken). So then the question of duplicates reduces to detecting the cases 
where the existing MAC<->IP mapping does not hold. If both of the hosts 
involved into collision are active, the router should be able to notice 
this just from the unicast traffic ?

>
> If we want both less multicast packets *and* a more robust DAD (including 
> efficiently handling DAD for sleeping nodes), then I don't see any approach 
> other than making some devices on the link be able to speak more 
> authoritatively about the addresses present on the link. Those devices can 
> try to build that state implicitly (gleaning from packets on the link), or 
> explicitly. (I'll try to capture the differences between those before next 
> week.)

The DAD also has the explicit function of detecting the duplicate MAC 
addresses. If we omit this function, I think the process can be simplified 
by quite a bit ?

Duplicate MAC addresses are an interesting corner case - but forcing 
everyone to pay the tax for this corner case might be something worth 
reevaluating ?

>> 
>>> In don't understand 4.9. Should I read it as a host shutting things down 
>>> if it goes to sleep even for a short time, and then waking up and 
>>> multicasting a
>> 
>> depends on the definition of "short". Some hosts nap during the 100ms 
>> interval between the 802.11 beacons. Obviously would not work here.
>> Maybe not do it within 5 seconds of turning the screen off.
>> But I certainly know my gadgets stop being reachable if I do not touch them 
>> for a day"
> The loss of reachability is expected.
> But there is also a question about the efficiency when the device wakes up. 
> Whether it needs to start from scratch (multicast RS, do DAD multicasts and 
> wait for a second), or whether it can do DNA (unicast a NS to the router(s) 
> to check it is on the same link) and avoid waiting for the lack of a response 
> to a DAD probe.

If the DNA succeeds - therefore we're on the same link, then we have some 
memory of it ?

Some more on this at [**] below.

Also, the DNA with a unicast NS makes me wonder - can the host achieve 
a similar function by sending a unicast RS *if* it remembers that the 
router earlier was sending the solicited RAs unicast ?

(Treat this as a thought experiment, I realize that I'm probably trying
to rewrite a dozen specs with one sentence ;-)

>> 
>> Sure it needs more whiteboarding. But if we assume one MAC address = one 
>> stack (this is a fair assumption I think?), it should be possible, here is 
>> a raw idea:
> Need to bring a whiteboard to London ... ;-)

I'll get a pack of napkins! :-)

>> 
>> By the destination of the RS being unicast, the router knows the host is 
>> "resolicit-capable". The source address contains the MAC address, so it is 
>> sufficient information to create a neighbor entry with a flag 
>> "resolicit-capable" in it.
> Or add a flag to the RS to say "I will re-solicit" ...

Yes. I tried to avoid having an explicit field - since the overall system 
should converge within 1 router lifetime anyway.

>> 
>> Subsequent neighbor entries with the same MAC address will inherit the 
>> "resolicit-capable" in it.
>> 
>> (Data structure detour: don't have to index by MAC address to do this.
>> Take two counting bloom filters "legacy hosts' MAC addresses" and 
>> "resolicit-capable hosts' MAC addresses". In case of a false positive 
>> match, prefer the membership in the "legacy hosts" to avoid blackout).
>> 
>> Keep the running counters of number of "resolicit-capable" ND entries and 
>> "legacy" ND entries.
> I can see how you increment those counters (based on seeing a RS with a new 
> MAC address.)

Assuming no explicit field: you increment the "legacy" counter upon the 
multicast RS from a host you do not have a neighbor entry for. Then you 
decrement the legacy counter and increment the "resolicit-capable" counter 
upon seeing a unicast RS.

> But when do you decrement them?
>
> (I don't think NUD from the router can be used for this, because the host can 
> be unreachable from the router for a few seconds due to radio issues, yet the
> host will still consider itself connected and not restart by sending an RS.)

Yes, I was counting this particular case as a "NUD is impatient" type of 
situation which should not happen :-).

But I think this is fixable relatively easily by having a single timer of 
"legacy quiet hosts sleepy interval": if you lost all legacy hosts, you wind up a timer 
and behave in a legacy fashion until it expires. If the legacy hosts 
reappear before this interval expires, you reset this timer.

I think the very same logic could govern the decision "to multicast or to 
drop?" above, as well... - if no legacy hosts and timer expired - drop, 
else multicast.

The value for the timer is probably something that would need to be set 
administratively. The bonus is that the default value can be "infinity" - 
that is, always send multicast RAs => today's behavior.


>> 
>> When it's time to send a periodic RA, look at the counters, and if the 
>> count of "legacy" hosts is zero, no need to send it.
>> 
>> This algorithm gives multiple deployment choices:
>> 
>> 1) "legacy" mode:
>> 
>> set the RA interval at 1/4 of the router lifetime. This way none of the 
>> hosts ever reaches the half remaining time, resolicits will never be sent, 
>> business as usual same as today.
>> 
>> 2) "resolicit-capable" mode:
>> 
>> set the RA interval at 3/4 of the router lifetime. Then by this time we 
>> will have seen the RS from all the capable nodes, so we can decide whether
>> to send a multicast RA or not.
> Presumably the RSs can be lost. One way to handle this is by agressive 
> retransmissions (no RA after 1 second, then resend RS). Another way is to 
> space the "retransmissions" inside the lifetime range e.g., by having the 
> host send a RS when 1/3 of the router lifetime has passed, next when 2/3 has 
> passed. (Generalize to k/N for N transmissions before giving up.)

Yes, indeed. I chose the "start at time T with retranstmits + exponential 
backoff" because this seems to take care better of a wider range of the 
possible loss on the medium: i.e. if you just space 3 retransmissions 
within the lifetime, as the loss increases, the chances to get the RA 
decrease. The exponentially decayed retransmits do not seem to have this 
problem - they autotune. They might create a denser burst in case of the 
loss though.

>> 
>> This of course needs to be worked on in order to avoid the synchronization 
>> issues (i.e. the host can not just blast an RS straight at half lifetime). 
>> But they are solvable: Assuming even the existing router lifetime limit of 
>> 2.5 hours, and RA interval of 1.5 hours, we have a space +- 0.5 hour of 
>> jitter.
>> 
>> Taking an arbitrary guess of 180000 hosts within that /64, a uniformly 
>> distributed jitter will give ~100pps of RSs which is more than manageable.
> Your suggestions made me realize the stuff I put in section 8.9 in 
> efficient-nd-05 is more complex than it needs be. No need to worry about 
> prefix and other lifetimes - sufficient to look at the default router 
> lifetime and make sure (by sending RSs) that the host hears from all the 
> routers. That's good.
>> 
>> NB: this is a very first napkin sketch, so it is fairly simplistic. But I 
>> think if we were to tinker a bit more with the timers, this can be made to 
>> work.
>> 
>> There is also a question - what happen if the router has to clean up the 
>> legacy host ND entry due to resource constraints - this can be taken care 
>> of by temporarily going into "legacy only" mode for a period of a couple of 
>> RA lifetimes.

> The router is free to just discard the NCEs - unless we change DAD to use 
> them in some proxy approach.
> Even if we change DAD that way, the router can just do the SAVI thing (send a 
> unicast NS to the host and see if it still there) - no need to multicast RAs 
> to clean up.
> However, the unicast NS cleanup (or any other cleanup driven by the router 
> expecting the host to respond) has issues with sleeping hosts. (I just 
> realize their might be different forms of sleep - completely off and will 
> take up based on a timer, or being woken up by arriving (unicast) packets. I 
> don't know if there is confusion around that and whether we need different 
> terms to make it more clear.)

I think the router might handle them in a FIFO fashion: keep them while 
it has enough space, and start purging them if there is a growing 
contention.

I think the timer idea I wrote about above, should take care of this case.

>> 
>> Of course, it requires the sleepy hosts to wake up every now and then. But 
>> with a lifted router lifetime limit, it will be every 9 hours.
> Assuming DAD is handled without involving the hosts.

yup.

>> 
>> Probably doable, but let's take a SWAG just to sanity check:
>> http://www.ti.com/lit/ds/symlink/cc3000.pdf and suppose they were one day 
>> to implement IPv6 with the similar power consumption.
>> 
>> I count the 802.11g, because of more efficient spectrum usage. This gives 
>> us maximum power consumption of 207ma, and a shutdown current of 5ua.
>> 
>> Now, assuming we couple it with something like 
>> http://www.atmel.com/Images/Atmel-2586-AVR-8-bit-Microcontroller-ATtiny25-ATtiny45-ATtiny85_Datasheet.pdf
>> which has standby of 0.1ua, and 12ma of active consumption (graph at page 
>> 173 of this pdf)
>> 
>> Let's say 20 seconds should be enough to make all the necessary 802.11 
>> arrangements, send the data, send the solicitation, and receive 
>> advertisement.
> That leaves plenty of time to do the current DAD.
>
> However, Margaret had some numbers a while back with lots more frequent 
> wakeups, but with very short runtime. I don't know if that was captured in 
> RFC 6574 or in Margarets slides from the workshop. In any case, one issue I 
> remember is that for Ipv4 the runtime was a lot less than one second, but 
> with IPv6 there was an additional 1 second to wait for DAD to complete which 
> blew the power budget.

This is interesting, and completely un-discussed so far aspect - 
battery-life impacting which does not have much to do with multicast ! So, 
essentially we have to wait 1 extra second before we can use the address.

Assuming it is indeed a problem, notice that this is a problem for the 
router-less segment as well => therefore should be addressed in the hosts 
themselves independently off the network. (i.e.: assuming a host 
self-assigns an IPv6 link-local address, probably the devices are 
*already* paying the tax on it, even in IPv4-only networks!)

I think we should square it into a separate corner and attack there :-)
(probably another draft?)

Couple of approaches for further discussion:

1) the host does not have to *wait wide awake* to receive the packet - 
since the reply will awake it equally. So it is a matter of more careful 
host programming to send a DAD NS, go back to a nap, and then awake either 
when NA is received or when 1 second expires.

2) investigate a different approach to a "1 second" timeout, treating it 
not as a fixed value, but as an envelope: at zero your chance 
of performing successful DAD is zero; then somewhere at around the 
inter-host RTT+sigma the usefulness of it is maximized, then further 
increase of the interval does not increase its usefulness much. [**] So, 
supposedly, the hosts that wake up and detect that they are on the same 
link, might use the memory about the network characteristics to shorten 
this interval.

--a

>
>   Erik
>> 
>> Now, assuming we power it off the typical NiMh 1.2V elements with 1800mAh 
>> capacity, the continous running time off it will be 1800*3600/220 = 29454 
>> seconds.
>> 
>> Let's assume for simplicity that we wake up every 8 hours, so this gives 60 
>> seconds per day. This gives us the active life span of 490 days.
>> 
>> Given that even the low self-discharge batteries 
>> (http://en.wikipedia.org/wiki/Nickel%E2%80%93metal_hydride_battery#Low_self-discharge_cells) 
>> have retain rate of 70%-85% within a year, probably this is a reasonable 
>> lifecycle (also for this reason I am not accounting for the standby 
>> current, it's comparable to self-discharge).
>> 
>> This is of course also a quick napkin sketch, a properly engineered 
>> approach would take into account the 802.11 maintenance stuff - and, also 
>> it's really the "extreme" case which does not listen to the packets while 
>> asleep - so the lifetime would certainly vary - but I think this shows that 
>> this is not a totally unreasonable path.
>> 
>> --a
>> 
>>> 
>>> Regards,
>>>    Erik
>>> 
>>> 
>>> 
>> 
>


From nobody Fri Feb 28 07:27:11 2014
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB15A1A084A for ; Fri, 28 Feb 2014 07:27:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.048
X-Spam-Level: 
X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0kE846i35gi for ; Fri, 28 Feb 2014 07:27:06 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 555BF1A0835 for ; Fri, 28 Feb 2014 07:27:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9652; q=dns/txt; s=iport; t=1393601219; x=1394810819; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=rz6lDltyOzyu17lDto7aklrXNNfwwf03EO5kSzzZElU=; b=dnClFOxDOzCtx31YjbkIUykBwcC0SRA72wQTM5eyAarwX/7zFDZxI3ZG HBdWbCCAt4OFHMBfXUmtPUAhU0vtVPJxrtYZvDFLw2JhIx93n6FsXBquf gfIrRgUyJa2sNfHWNgPZT4IxmfyTcuIcf3rAyQCgVVKq03J6j9JbVEsiF o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAOSpEFOtJXHB/2dsb2JhbABRCIMGgRLBH4EUFnSCJQEBAQMBJxECNgkFCwsYLlcGDod2CMtKF419AlYHhDcElE+KNYthgy6BZ0I
X-IronPort-AV: E=Sophos;i="4.97,562,1389744000"; d="scan'208";a="23976075"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-8.cisco.com with ESMTP; 28 Feb 2014 15:26:59 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1SFQxql004364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Feb 2014 15:26:59 GMT
Received: from [10.61.221.73] (10.61.221.73) by xhc-rcd-x10.cisco.com (173.37.183.84) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 28 Feb 2014 09:26:57 -0600
Date: Fri, 28 Feb 2014 16:26:35 +0100
From: Andrew Yourtchenko 
X-X-Sender: ayourtch@ayourtch-mac
To: Erik Nordmark 
Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast
In-Reply-To: <530C9CFD.2000409@acm.org>
Message-ID: 
References: <5305AF13.5060201@acm.org> <75B6FA9F576969419E42BECB86CB1B89115F99A9@xmb-rcd-x06.cisco.com>  <75B6FA9F576969419E42BECB86CB1B89115F9BAE@xmb-rcd-x06.cisco.com>  <530C9CFD.2000409@acm.org>
User-Agent: Alpine 2.00 (OSX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="US-ASCII"
X-Originating-IP: [10.61.221.73]
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/vDMfc5XQFgY0D3yYf2o38nH9xHA
Cc: IETF IPv6 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Feb 2014 15:27:09 -0000

Erik,

On Tue, 25 Feb 2014, Erik Nordmark wrote:

> On 2/21/14 12:36 PM, Andrew Yourtchenko wrote:
>> 
>> Myself I did not like this portion of my reply with no quantifiable data 
>> (because operating on a basis of a belief is not a good engineering).
>> 
>> I happened to have a couple of hours of offline time, during which I tried 
>> to sketch the scenario and try to get as far as I can without building a 
>> lab.
>> 
>> It's a *very rough sketch*. If you think there can be parts that can be 
>> made better in it, tell me.
> Andrew,
> I like this sketch. A few comments below.
>> 
>> The initial assumptions for this thought experiment are as follows:
>> 
>> 1) We have 10000 clients in a single /64.
>> 
>> 2) There are multiple APs that bridge the traffic from wired onto
>> wireless medium, with the client count limited to 100 per AP.
>> 
>> 3) there is 20x speed difference between unicast transmission and
>> multicast transmission.: the effective multicast speed is assumed to be
>> 1 mbps, the effective unicast speed is assumed to be 20mbps data rate.
>> 
>> 4) The APs are assumed to be "Naive" i.e. they do not perform any snooping
>> nor multicast->unicast conversions, but at the same time they are able to 
>> bridge the unicast traffic without flooding it between multiple access 
>> points. I.e. we assume a model where we have a single router (or an FHRP 
>> pair) and a set of 100 APs bridging the traffic.
>> 
>> (Corollary from the above: The effective unicast capacity is 100*20mbps, 
>> whereas the effective multicast capacity is 1*1Mbps, therefore the 
>> difference in throughput is 1000-fold).
>> 
>> Let's first consider the steady state. Suppose each host downloads
>> a file at 0.1 mbps.  Within each AP, therefore we have a 50% capacity 
>> utilization (0.1*100 = 10Mbps, we have 20 Mbps capacity).
>> 
>> It's easy to see this comfortably accomodates all the hosts. Obviuously
>> the unicast NUD in this traffic is fairly minimal, so I don't think it's 
>> even worth to count how much it is.
>> 
>> Now, lets look at a potential failure.
>> 
>> At the time of the NUD probe, it's enough to lose the 3 retries,
>> spaced 1 second apart.  The default reachable time is 30 seconds,
>> with the random jitter of 0.5 of that.
>> 
>> So, all that is needed to achieve a mass NUD failure is a ~30 second
>> outage during the period when all the hosts are sending the traffic.
>> 
>> A reboot of the majority of the networking gear takes several times longer 
>> than this.
>> 
>> Therefore, a crash of the default gateway during the peak hour is
>> a one guaranteed trigger for this to happen.
>> 
>> So, now we have a situation of 10000 hosts which have deleted their default 
>> gateway from the neighbor table, and send the multicast neighbor 
>> solicitations for it.
>> 
>> Assume the NS is 64 bytes, 10000 hosts sending such a packet means 64 bytes 
>> * 8 bit * 10000 hosts = 5120000 bits/sec - or, 5 mbps.

> Just to make it clear, each NS retransmissions is 5 Mbits and the 
> retransmission time is 1 second. Hence with 4861 we get 5 mbps for 3 seconds. 
> However, they hosts aren't that likely to all discover the NUD failure in the 
> same 3 second window. With ReachableTime=30 seconds it depends on when there 
> last successful NUD probe or higher-level reachability advise can in. Hmm - 
> with TCP the reachability advise might come with every left window edge 
> advancement i.e. they would synchronize quite closely.

Yes, it's a bit of a fringe assumption here of all the hosts being active 
and then losing the connectivity, and somewhat uniform implementations of 
TCP (or, stuff like name resolutions). In reality I think they will be 
spaced more.

>
>> 
>> Note, that this is only the shared bandwidth downstream back to the hosts - 
>> the airtime spent by the upstream traffic is 20x faster, so I am 
>> gratuitously discarding it.
>> 
>> Since the APs can not send the traffic at this rate, obviously, we will
>> need to drop some of it. Note, if the clients succeed with the ND to the 
>> default gateway, they will start streaming data again, so the effective 
>> multicast throughput will drop to the 0.5 mbps as soon as the noticeable 
>> portion of clients recovers.
> While the multicast NS will see downstream drops, what matters for the 
> resolution is that the router receives it and responds. Thus why wouldn't 
> that part work?
> The NA from the router will be unicast so if that unicast isn't dropped due 
> to the multicasts then it should resolve quickly. I don't know if unicast is 
> prioritized higher than multicast or not.
>
> (We'll see downstream overload due to the multicasts, but that might just 
> last for 1 second if the NS/NA to/from the router gets through.)

Yes, since the router is on the wired, the 
bandwidth degradation due to a "dummy" multicast retransmission is the 
biggest problem. The NS will go unicast over the air, then go to the wired 
+ multicast over the air, and the unicast reply from the default 
gateway on the wired will go over unicast.

>
>> 
>> Let's assume the best case of 20% of the clients managing to recover within 
>> the first second.
>> 
>> As we are approaching full recovery, the lesser number of clients will be 
>> able to get their multicast NS sent because the airtime is being taken by 
>> the payload traffic. Anyway, let's discard that and assume that every 
>> second 20% of the clients will recover.
>> 
>> This means that the recovery of the full set of the clients in this 
>> conditions will take an *absolute* minimum of 5 seconds.
>> 
>> Did I prove myself wrong ? Seems so. We can see that with some of the 
>> relaxed assumptions I took, the hosts seem to recover.
>> 
>> But, let's add to this a little bit of mDNS, and other multicast-loving 
>> protocols, which tend to generate a fair chunk of traffic when they detect 
>> the network was "restored".
>> 
>> This can shrink the available capacity several times. Add to this that the 
>> host does not necessarily stream at 100kbps, but might have higher data 
>> rates, and I think we can consider the available
>> multicast capacity at startup to be 1/10th of what it is in theory.
> Yes, in general TCP will fill the pipe thus at each AP all of the downstream 
> bandwidth will be used.
>
> But if the streaming comes via the default router (which crashed or was 
> unreachable for a few seconds), then the stream would also slow down due to 
> TCP, in which case there is less of a multicast overload issue. There might 
> be cases where this TCP slowdown doesn't happen though.

Yes, indeed. Also, given the high utilisation of the media at that point, 
I wonder if the cross-channel interference will play a bigger role, 
therefore affecting the results.

This seems like an extremely tricky beast to model with any reasonable 
accuracy!

--a



>
>  Erik
>
>> 
>> This is where the things may become interesting - 1/10th of the capacity 
>> means that it will take not 5, but 50 seconds for all the hosts to recover.
>> 
>> This means that the hosts which recovered in the very first second, will 
>> already be sending NUD traffic while the network is still under stress. If 
>> these packets are lost, the hosts might back into the pool of the "orphans" 
>> who are sending the multicast, because they delete their neighbor entry.
>> 
>> There are some other things to consider:
>> 
>> - I deliberately kept the scenario here with *one* ND entry.
>> Assuming your hosts are talking with 3-4 other hosts besides the default 
>> gateway. This increases the load and proportionally makes the dangerous 
>> state easier to achieve.
>> 
>> - another factor that I am omitting - that such a storm of ND onto the 
>> default gateway might cause rate-limiting of the control plane packets on 
>> the gateway. With some of the limits being as low as 1000pps, this might 
>> give a recovery time on the order of minutes even without the wireless 
>> multicast being the bottleneck, yet still resulting in a lot of multicast 
>> NS in the air still during the slow recovery.
>> 
>> This is about as precise of the construct I can build.
>> 
>> Is it perfect ? No, by no means. It also does assume that in the case of 
>> the default gateway the wireless performance will be limiting factor - I 
>> think it won't - so it's more of an appropriate scenario for a case of a 
>> p2p communications on the network. The default-gateway-only will be 
>> inherently much more stable, I think - because the multicast on the wired 
>> side is fast, so the drops on the wireless side will not matter.
>> 
>> It's probably worth it to change the text into "There is potential for the 
>> failing NUD to *contribute* to a longer recovery and possible creation of 
>> the locked situation in the case of flash failure - but the exact 
>> quantification of the impact in such an environment is a topic of further 
>> study".
>> 
>> And then maybe I could dump the above thought experiment into a separate 
>> draft, to see if the folks could contribute to the experiment / maybe 
>> someone could run it - and reference it in this item ?
>> 
>> It seems like an interesting area to dig a bit more in - creating a 
>> suitable model and playing with the parameters to see where it breaks seems 
>> like a useful exercise to understand how many hosts can there be in a 
>> single /64 on WiFi with a "naive" set of access-points.
>> 
>> Thoughts ?
>> 
>> --a
>> 
>


From nobody Fri Feb 28 14:53:58 2014
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73451A0156 for ; Fri, 28 Feb 2014 14:53:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.821
X-Spam-Level: ***
X-Spam-Status: No, score=3.821 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SB_o9RvXT3T for ; Fri, 28 Feb 2014 14:53:55 -0800 (PST)
Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDC11A013E for ; Fri, 28 Feb 2014 14:53:54 -0800 (PST)
Received: by mail-we0-f172.google.com with SMTP id u56so1101963wes.31 for ; Fri, 28 Feb 2014 14:53:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=CsZupdGsRWzfMq35TsJHF4pKtrErtnmsQlYpx4wCSt0=; b=GKHsWMhv29+YDCAdNvcPgEqJ0x9cVpQ6OmlNW3MgtEyXlA3cCzi3njZW0YO/22hoVm AGllAw4KRw2VnE72ee0A0qfrwMGRiH5nrPEoka7dcAzJ4qhq9qUyVgp1QVZU3yCSEwPr +om8YjZkBYirFLMHUvIEvYYT7ScdbLtnq8kV9i+TTsYp4hmqWmP/G0HK/BztV+I9repq rgpcL6J9zDrdflgTOSqqX+cCUEcljY1uc+GG1j736OApFW8AuYDvc2PmioCuLJGKNOmu fOkfa8yXpniEz7fkGk/y5wW7QkoG0PfZ9S5/Eyt65BST/L/gdMzyJV3aEc8/4lGKfPhQ uX/w==
MIME-Version: 1.0
X-Received: by 10.194.78.16 with SMTP id x16mr306670wjw.86.1393628032548; Fri, 28 Feb 2014 14:53:52 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.120.167 with HTTP; Fri, 28 Feb 2014 14:53:52 -0800 (PST)
In-Reply-To: <530FA94B.3050802@acm.org>
References: <20140214235734.2509.63069.idtracker@ietfa.amsl.com> <52FF115C.30001@acm.org>  <530FA94B.3050802@acm.org>
Date: Fri, 28 Feb 2014 14:53:52 -0800
X-Google-Sender-Auth: jjm0AGJZLtWcNqttcHUKGKwWA9Q
Message-ID: 
Subject: Re: New Version Notification for draft-chakrabarti-nordmark-6man-efficient-nd-05.txt
From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= 
To: Erik Nordmark 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/C0k85DDIQplMDs_QxSnv8hEEJUs
Cc: IETF IPv6 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Feb 2014 22:53:57 -0000

At Thu, 27 Feb 2014 22:08:27 +0100,
Erik Nordmark  wrote:

> But we seemed to not have edited the rest of the draft correctly around
> DAD, including the bootstrapping section.
> As the draft currently stands DAD for link-locals is (or "can be" given
> the lack of editorial clarity) replaced by NS/ARO. But address
> resolution for link-local targets needs to be done for using multicast NS.

I don't understand how it works in the bootstrap stage.  To send the
NS/ARO for a link-local address (on bootstrap), the host should first
know the registrar's address.  But the host can't get the information
by unicast RS-RA exchange since the source address of the RS would
need to be the link-local address to prove unique.  Or am I
misunderstanding your intent?

--
JINMEI, Tatuya