From Fred.L.Templin@boeing.com Fri Jan 3 11:47: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 AAAD51AE018 for ; Fri, 3 Jan 2014 11:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 pZCDFftIATeA for ; Fri, 3 Jan 2014 11:47:35 -0800 (PST) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 18A6E1AE009 for ; Fri, 3 Jan 2014 11:47:35 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s03JlRSJ029393; Fri, 3 Jan 2014 11:47:27 -0800 Received: from XCH-PHX-309.sw.nos.boeing.com (xch-phx-309.sw.nos.boeing.com [130.247.25.163]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s03JlOUl029379 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Fri, 3 Jan 2014 11:47:24 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-PHX-309.sw.nos.boeing.com ([169.254.9.87]) with mapi id 14.03.0158.001; Fri, 3 Jan 2014 11:47:23 -0800 From: "Templin, Fred L" To: IETF IPv6 Mailing List Subject: RE: AERO and SEAL Thread-Topic: AERO and SEAL Thread-Index: Ac79BdovFZGCFx4sTrSR9PegouXNoQAlt7iQAsevDfA= Date: Fri, 3 Jan 2014 19:47:23 +0000 Message-ID: <2134F8430051B64F815C691A62D9831818C8E1@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D98318180CD6@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D98318181B45@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D98318181B45@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.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, 03 Jan 2014 19:47:36 -0000 Happy New Year. New versions of AERO and SEAL have been posted (see links below) and should remain stable for the near future. When considering whether to read AERO, please understand that it introduces a new IPv6 address format known as the AERO address. The address format both provides a means for automatic generation of link local addresses to assign to the tunnel interface as well as a means for linking IPv6 neighbor discovery with IPv6 routing. An AERO address is formed by embedding the IPv6 prefix of a node's delegated prefix within the interface identifier of an IPv6 link local address. So, for example, if a node has been delegated the prefix: "2001:db8:1:0::/56", it can assign the link-local address "fe80::2001:db8:1:0" to its AERO interface. More details are available in the documents, which are found here: http://tools.ietf.org/html/draft-templin-aerolink-01 http://tools.ietf.org/html/draft-templin-intarea-seal-68 As always, comments and questions are welcome. Thanks - Fred fred.l.templin@boeing.com From brian.e.carpenter@gmail.com Sun Jan 5 14:07: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 2517B1AD6B9; Sun, 5 Jan 2014 14:07:16 -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 vWRKVVMpDY0U; Sun, 5 Jan 2014 14:07:14 -0800 (PST) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0F51AD69E; Sun, 5 Jan 2014 14:07:14 -0800 (PST) Received: by mail-pb0-f48.google.com with SMTP id md12so17683889pbc.21 for ; Sun, 05 Jan 2014 14:07:06 -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=db2e1Irsh5E3iTOME4puKOYCCgEAycDTkGJ2lRJJqqg=; b=oatU8ajMcWlu7T7AoDt1tS8ACmOOfn59X4PMTJEDwvxo7I3On+5xCSOI0kNT7/rSSB oU2Izx3NlFJBsMiXlVL3RdMC9LGb7bIhSHUtpxiEBPHIp26ceXdmToKPSczMH/JpcJ+O C6luzvkG93l3PLSxNYmtup9Xa5Z7nrzF3kRag7ot9LzSft33DCaVStvISaSoKzoPE2IS x6wOFjxtzuWKg/TpXu1PdjvaNrWhtTXCBQhd846a2CYsIzhvjjwv38iKv1EmaBxLBDYL GYp/reFyRfmBIbu9hnIiM8MAuq4aXzTI+6OPaksWdJzU4gKIA+1zWNz+grQV2gL/E1xj D2pw== X-Received: by 10.69.21.1 with SMTP id hg1mr118001356pbd.67.1388959626037; Sun, 05 Jan 2014 14:07:06 -0800 (PST) Received: from [192.168.178.21] (97.197.69.111.dynamic.snap.net.nz. [111.69.197.97]) by mx.google.com with ESMTPSA id yd4sm124051845pbc.13.2014.01.05.14.07.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 05 Jan 2014 14:07:05 -0800 (PST) Message-ID: <52C9D788.8060606@gmail.com> Date: Mon, 06 Jan 2014 11:07:04 +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-00.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: Sun, 05 Jan 2014 22:07:16 -0000 Hi, A group of us put this together following a discussion some weeks ago on the v6ops list about the 64-bit boundary in IPv6 addresses. Discussion belongs in 6man, please. This draft is incomplete but we'd welcome input. Let me underline an important comment in the introduction: _The purpose of this document is to analyse the issues around this question. We make no proposal for change, but we do analyse the possible effects of a change._ Brian + co-authors -------- Original Message -------- Subject: I-D Action: draft-carpenter-6man-why64-00.txt Date: Sun, 05 Jan 2014 13:59:17 -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-00.txt Pages : 14 Date : 2014-01-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-00 From ietf-secretariat-reply@ietf.org Mon Jan 6 06:18: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 2D5AB1ADFD7 for ; Mon, 6 Jan 2014 06:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 KCvUUvRn0Xfm; Mon, 6 Jan 2014 06:18:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1711ADFDA; Mon, 6 Jan 2014 06:18:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: 6man-chairs@tools.ietf.org, draft-ietf-6man-stable-privacy-addresses@tools.ietf.org, ipv6@ietf.org Subject: ID Tracker State Update Notice: X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140106141811.31027.25465.idtracker@ietfa.amsl.com> Date: Mon, 06 Jan 2014 06:18:11 -0800 From: IETF Secretariat 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: Mon, 06 Jan 2014 14:18:12 -0000 State changed to IESG Evaluation from Waiting for Writeup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-6man-stable-priv= acy-addresses/ From Fred.L.Templin@boeing.com Mon Jan 6 08:08: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 00A1D1AE073 for ; Mon, 6 Jan 2014 08:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 KzX84ri2Gkik for ; Mon, 6 Jan 2014 08:08:05 -0800 (PST) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6BD1AE063 for ; Mon, 6 Jan 2014 08:08:05 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s06G7vTc000570; Mon, 6 Jan 2014 08:07:57 -0800 Received: from XCH-PHX-510.sw.nos.boeing.com (xch-phx-510.sw.nos.boeing.com [10.57.37.27]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s06G7op6000459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 6 Jan 2014 08:07:50 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-PHX-510.sw.nos.boeing.com ([169.254.10.108]) with mapi id 14.03.0158.001; Mon, 6 Jan 2014 08:07:50 -0800 From: "Templin, Fred L" To: Brian E Carpenter , 6man Subject: RE: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] Thread-Topic: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] Thread-Index: AQHPCmKCHEKzqaIg8UualVdPQhn+uJp33VVA Date: Mon, 6 Jan 2014 16:07:49 +0000 Message-ID: <2134F8430051B64F815C691A62D9831818E598@XCH-BLV-504.nw.nos.boeing.com> References: <52C9D788.8060606@gmail.com> In-Reply-To: <52C9D788.8060606@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.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, 06 Jan 2014 16:08:09 -0000 Hello Brian and co-authors, The draft looks good to me. In Section 3, paragraph 3, please add ISATAP [RFC5214] and AERO [I-D.templin-aerolink] to the list of "IPv6-over-foo" documents. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > Sent: Sunday, January 05, 2014 2:07 PM > To: 6man > Subject: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] >=20 > Hi, >=20 > A group of us put this together following a discussion some weeks > ago on the v6ops list about the 64-bit boundary in IPv6 addresses. > Discussion belongs in 6man, please. >=20 > This draft is incomplete but we'd welcome input. Let me underline > an important comment in the introduction: >=20 > _The purpose of this document is to analyse the issues around this > question. We make no proposal for change, but we do analyse the > possible effects of a change._ >=20 >=20 > Brian + co-authors >=20 > -------- Original Message -------- > Subject: I-D Action: draft-carpenter-6man-why64-00.txt > Date: Sun, 05 Jan 2014 13:59:17 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : Analysis of the 64-bit Boundary in IPv6 Address= ing > Authors : Brian Carpenter > Tim Chown > Fernando Gont > Sheng Jiang > Alexandru Petrescu > Andrew Yourtchenko > Filename : draft-carpenter-6man-why64-00.txt > Pages : 14 > Date : 2014-01-05 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-carpenter-6man-why64/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-carpenter-6man-why64-00 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From markzzzsmith@yahoo.com.au Mon Jan 6 12: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 32B1E1AE14D for ; Mon, 6 Jan 2014 12:51:55 -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 V2nNwH_pf01I for ; Mon, 6 Jan 2014 12:51:53 -0800 (PST) Received: from nm2-vm1.bullet.mail.bf1.yahoo.com (nm2-vm1.bullet.mail.bf1.yahoo.com [98.139.213.158]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC2B1AE110 for ; Mon, 6 Jan 2014 12:51:53 -0800 (PST) Received: from [66.196.81.174] by nm2.bullet.mail.bf1.yahoo.com with NNFMP; 06 Jan 2014 20:51:45 -0000 Received: from [98.139.212.197] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 06 Jan 2014 20:51:45 -0000 Received: from [127.0.0.1] by omp1006.mail.bf1.yahoo.com with NNFMP; 06 Jan 2014 20:51:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 47126.19047.bm@omp1006.mail.bf1.yahoo.com Received: (qmail 19787 invoked by uid 60001); 6 Jan 2014 20:51:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1389041504; bh=Dre2wC8TQ7vJXgvKq+SQpZDMm7/KI7XLX7Lj1ycq86Y=; 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=cY4yYjtlWCEyLjcOyc/fFVYb+uVOQocSVCdCRMtqcHbBj7ZlkFbVr3SaI+ZucmM82zjwd/R2TMNBkArXuoJHUDLYlxekGqvTeiVTr93IRrlTt7xzLu64cZpW+pKlK77wiTJFyDhL2ZBFG9FhDSnAluzcktVHQVkiyu1FSDwNfFs= 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=hVRfSqJ4u+T/ZFztiwZGDt5QxxMYfQ1m6PsHD6ZxsMonu4/N+R/mljt54NiDJUy2MAbjilqcqTyKEkiuEyAZrDU7TJi5ytX8LKvGp0o0LQT4ARSLj7nqZldCDrGZeTZNSYX43TM49wFtpoN6E01YFr4DPTAnv4i7gRg8bUXGgu4=; X-YMail-OSG: WbFvc1sVM1nIuO7vARxm4iEEB0LwY6AAK9UE7lT1Vxg23Ov RHDEbUFO3j1e96UrWFbGOeVY108r5lGJcJ4NlAsrZAU3stNYLgwcJRkKs3P. BsiVUx22NGF2iTeHGIPmQ5vrZpkJtr6E7n1Q.N_Zf.I5ZCuB2yA.aM7Nv.1P PgXxnawtjIGigCONpFXwD3B_YSffwHQ21zCExWm28yBLBAgMYFvCA5OZb71X S0OJ9plTQ33LnZioWlpZ80thUz1LdKQmnP6Vd.8SL1P3K3nKXS71fQQWctrq 9CthyUxFQW_FhXK0KxJEwu_Em3BvYU_Oqjc8LBx4qk5KNTMwXSEM_tWR_jZ1 CYrt7K9zRw4KQqqVi9DqT20MVz6rVkELUlY414Hf5p4Yr8DdbfX6NcgyaPEw gMiHK1zfQ.Xq3DEUwtNltMpCspghDM.kneqfXRpKo8VfLu4GUT1JTL.EZAgE C_LdKDbt2AqN57rKUrYaZ7.USHq5HFxWdF.dz7bVgKECmupsTiNUu.a1uyyw qnNaqAmp3UFLKh8a2gNjRQ3rzhwe74JB.tX_NZB8gzIsUX8gPjfK0QUW0wLs GJNdR7mxrvqC_92WEnRyn Received: from [150.101.221.237] by web161905.mail.bf1.yahoo.com via HTTP; Mon, 06 Jan 2014 12:51:44 PST X-Rocket-MIMEInfo: 002.001, SGksCgpJJ3ZlIGhhZCBhIHF1aWNrIHJlYWQgdGhyb3VnaCwgSSB0aGluayB0aGlzIGRvY3VtZW50IHdvdWxkIGJlIHF1aXRlIHVzZWZ1bC4KCk9uZSB0aGluZyBJIHRoaW5rIHdvdWxkIGJlIGdvb2QgdG8gY2FwdHVyZSBpcyBhIGJpdCBvZiB0aGUgaGlzdG9yeS9yYXRpb25hbCBiZWhpbmQgdGhlIGNob2ljZSBvZiA2NCBJSUQuwqAKCkkgYmVjYW1lIGF3YXJlIG9mIHRoYXQgaGlzdG9yeSB2aWHCoENocmlzdGlhbiBIdWl0ZW1hJ3PCoCJJUHY2OiBUaGUgTmV3IEludGVybmV0IFByb3RvY29sICgybmQgRWRpdGkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.172.614 References: <52C9D788.8060606@gmail.com> Message-ID: <1389041504.19037.YahooMailNeo@web161905.mail.bf1.yahoo.com> Date: Mon, 6 Jan 2014 12:51:44 -0800 (PST) From: Mark ZZZ Smith Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] To: Brian E Carpenter , 6man In-Reply-To: <52C9D788.8060606@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.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: Mon, 06 Jan 2014 20:51:55 -0000 Hi,=0A=0AI've had a quick read through, I think this document would be quit= e useful.=0A=0AOne thing I think would be good to capture is a bit of the h= istory/rational behind the choice of 64 IID.=A0=0A=0AI became aware of that= history via=A0Christian Huitema's=A0"IPv6: The New Internet Protocol (2nd = Edition)" book, I think it would be good if that history was a bit more wid= ely available to explain and justify the choice.=0A=0ARegards,=0AMark.=0A= =0A=0A----- Original Message -----=0A> From: Brian E Carpenter =0A> To: 6man =0A> Cc: =0A> Sent: Monday, 6= January 2014 9:07 AM=0A> Subject: [Fwd: I-D Action: draft-carpenter-6man-w= hy64-00.txt]=0A> =0A> Hi,=0A> =0A> A group of us put this together followin= g a discussion some weeks=0A> ago on the v6ops list about the 64-bit bounda= ry in IPv6 addresses.=0A> Discussion belongs in 6man, please.=0A> =0A> This= draft is incomplete but we'd welcome input. Let me underline=0A> an import= ant comment in the introduction:=0A> =0A> =A0 _The purpose of this document= is to analyse the issues around this=0A> =A0=A0=A0question.=A0 We make no = proposal for change, but we do analyse the=0A> =A0=A0=A0possible effects of= a change._=0A> =0A> =0A> =A0=A0=A0Brian + co-authors=0A> =0A> -------- Ori= ginal Message --------=0A> Subject: I-D Action: draft-carpenter-6man-why64-= 00.txt=0A> Date: Sun, 05 Jan 2014 13:59:17 -0800=0A> From: internet-drafts@= ietf.org=0A> Reply-To: internet-drafts@ietf.org=0A> To: i-d-announce@ietf.o= rg=0A> =0A> =0A> A New Internet-Draft is available from the on-line Interne= t-Drafts directories.=0A> =0A> =0A> =A0 =A0 =A0 =A0 Title=A0 =A0 =A0 =A0 = =A0=A0=A0: Analysis of the 64-bit Boundary in IPv6 Addressing=0A> =A0 =A0 = =A0 =A0 Authors=A0 =A0 =A0 =A0=A0=A0: Brian Carpenter=0A> =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Tim Chown=0A> =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fernando Gont=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 Sheng Jiang=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 Alexandru Petrescu=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 Andrew Yourtchenko=0A> =A0=A0=A0 Filename=A0 =A0 =A0 =A0 := draft-carpenter-6man-why64-00.txt=0A> =A0=A0=A0 Pages=A0 =A0 =A0 =A0 =A0= =A0=A0: 14=0A> =A0=A0=A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2014-01-05=0A> =0A> = Abstract:=0A> =A0=A0=A0The IPv6 unicast addressing format includes a separa= tion between the=0A> =A0=A0=A0prefix used to route packets to a subnet and = the interface identifier=0A> =A0=A0=A0used to specify a given interface con= nected to that subnet.=0A> =A0=A0=A0Historically the interface identifier h= as been defined as 64 bits=0A> =A0=A0=A0long, leaving 64 bits for the prefi= x.=A0 This document discusses the=0A> =A0=A0=A0reasons for this fixed bound= ary and the issues involved in treating=0A> =A0=A0=A0it as a variable bound= ary.=0A> =0A> =0A> The IETF datatracker status page for this draft is:=0A> = https://datatracker.ietf.org/doc/draft-carpenter-6man-why64/=0A> =0A> There= 's also a htmlized version available at:=0A> http://tools.ietf.org/html/dra= ft-carpenter-6man-why64-00=0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A>= --------------------------------------------------------------------=0A> I= ETF IPv6 working group mailing list=0A> ipv6@ietf.org=0A> Administrative Re= quests: https://www.ietf.org/mailman/listinfo/ipv6=0A> --------------------= ------------------------------------------------=0A> From swmike@swm.pp.se Tue Jan 7 00:46: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 331871AE4AF for ; Tue, 7 Jan 2014 00:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.389 X-Spam-Level: X-Spam-Status: No, score=-4.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 TKvVZ-8qGRwM for ; Tue, 7 Jan 2014 00:45:58 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2365C1AE4AD for ; Tue, 7 Jan 2014 00:45:57 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CA6CF9C; Tue, 7 Jan 2014 09:45:46 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B94B49A; Tue, 7 Jan 2014 09:45:46 +0100 (CET) Date: Tue, 7 Jan 2014 09:45:46 +0100 (CET) From: Mikael Abrahamsson To: Mark ZZZ Smith Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 In-Reply-To: <1387528272.76757.YahooMailNeo@web161901.mail.bf1.yahoo.com> Message-ID: References: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> <1387528272.76757.YahooMailNeo@web161901.mail.bf1.yahoo.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-283073891-1389084346=:20074" Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 07 Jan 2014 08:46:00 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-283073891-1389084346=:20074 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 20 Dec 2013, Mark ZZZ Smith wrote: > Perhaps it might be better to treat the link as an NBMA subnet, and use > RFC2491 "IPv6 over Non-Broadcast Multiple Access (NBMA) networks" to > eliminate all multicasts (including ND, MLD and application), except > perhaps RAs with a flag that indicate the link is operating in NBMA > mode (with RA timers larger than defaults - IIRC, the max router age > value is 90 minutes, so unsolicited RAs can be around 30 minutes apart)? I have had similar thoughts. I would like to have mode where no discovery is done at all anymore, and in order to support legacy hosts, one way of doing that would be: Legacy hosts see RAs with M=1, and they are handed address using DHCPv6 IA_NA if they ask for it. They will not see any on-link prefix, and will send all traffic through the router. The router will install ND entry based on lifetime of the DHCPv6 IA_NA. EAH will be able to do autoconfig by means of seeing an on-link /64 that is in a RA option that differs in a way that legacy hosts won't use it (preferrably also just unicasted to EAH by the router in response to RS). EAH use ARO to register their address just as in the draft. If the router gets a packet to an address it doesn't have in the ND table, it just drops the packet. All traffic on the LAN is routed through the router, and optionally it can choose to send unicast redirects if it feels traffic is to hosts in the same L2 network. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-283073891-1389084346=:20074-- From v6ops@globis.net Tue Jan 7 03:11: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 D755A1ADBD7 for ; Tue, 7 Jan 2014 03:11:47 -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 LohNWx5IvwLM for ; Tue, 7 Jan 2014 03:11:46 -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 BCDC01AD9B8 for ; Tue, 7 Jan 2014 03:11:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 83F1E870F8F; Tue, 7 Jan 2014 12:11:36 +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 IEPY-oFkf2CW; Tue, 7 Jan 2014 12:11:36 +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 5E3A1870F8E; Tue, 7 Jan 2014 12:11:36 +0100 (CET) Message-ID: <52CBE0E6.5020107@globis.net> Date: Tue, 07 Jan 2014 12:11:34 +0100 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] References: <52C9D788.8060606@gmail.com> In-Reply-To: <52C9D788.8060606@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 07 Jan 2014 11:11:48 -0000 Brian E Carpenter wrote: > Hi, > > A group of us put this together following a discussion some weeks > ago on the v6ops list about the 64-bit boundary in IPv6 addresses. > Discussion belongs in 6man, please. > > This draft is incomplete but we'd welcome input. Let me underline > an important comment in the introduction: > > _The purpose of this document is to analyse the issues around this > question. We make no proposal for change, but we do analyse the > possible effects of a change._ > > > Brian + co-authors > > -------- Original Message -------- > Subject: I-D Action: draft-carpenter-6man-why64-00.txt > Date: Sun, 05 Jan 2014 13:59:17 -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-00.txt > Pages : 14 > Date : 2014-01-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-00 > > I have read this draft. some comments: Where exactly is the requirement that IPv6 has to use /64 prefix length really enshrined? I think the draft can help clarify that, and that alone makes it worthwhile proceeding. I humbly disagree with the conclusions in Section 9. The argument seems to assume that all n hosts must be allocated within one single prefix with a prefix length >> 64. Therefore it assumes that increasing prefix length reduces attack search space (given some knowledge of one or more active IPv6 addresses) IMHO Address space is address space. Allocation density is allocation density. IPv6 supports multiple prefixes per link and the concept of determining "on link prefixes" via rfc5942 (unlike the "subnet mask" mechanism of IPv4). It should be perfectly feasible to allocate a /64 to a router interface in an IPAM tool, but then configure the equivalent of n prefixes each containing 1 or 2 address with prefix length /128 or /127 (depending on the implementation) for n hosts and which are equally sparsely assigned across the /64, and all sharing a single L2 link. Even end node to end node communication should flow directly (avoiding the router) as these prefixes could be marked "on link" via the AdvOnLinkFlag = L flag. Anyway, in the majority of modern day wired deployments, the delta cost of L3 over L2 is minimal, as the most dominant form of wired LAN (Ethernet) are commonly switched in silicon, and multicast has to be emulated. Wired Ethernet has in effect become a point to point protocol. So deploying a dedicated L3 connection per end host is both technically and financially feasible, and may have significant operational benefits in certain scenarios. Allocating a /64 for each such port on a L3 switch is sub optimal IMHO. And by the same privacy argument, allocating n hosts sparsely over a single /64 of address space spread over multiple L3 interfaces would have the same net effect for off-net attackers as n hosts sharing a flat L2 LAN using a single /64, with the added advantage that even locally the individual end nodes would not be able to passively observe each other's traffic or addresses (advantageous in shared hosting environments). An attacker that happens to discover the address of node A would not find this information helpful in attempts to locate node B, any more than if it were a flat /64. So to me it's a non-relevant argument one way or the other. Section 2.2 It may not be a widely held belief, but I remain concerned about the potential for resource exhaustion for any number of processes due to the "massive over sizing" of prefixes to /64: any number of untested processes that track state based on /128 IPv6 address could be attacked. The flip side of expanding privacy through address obfuscation at IID level is that the source space available for attacks also increases. ND cache exhaustion is probably just the first issue we've discovered of many that exist. This may have knock on operational consequences, which in the IPv4 world have relied on the scarcity of IPv4 address space to be able to operate correctly under stress scenarios. We're going to discover who has been swimming naked when the tide goes out. Call that FUD, or operational expediency, whichever you like. BCP38 has saved me on a number of occasions when all else has failed. -- Regards, RayH From alexandru.petrescu@gmail.com Tue Jan 7 05:23: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 41B561AE057 for ; Tue, 7 Jan 2014 05:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, 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 94CgzRuTZVrW for ; Tue, 7 Jan 2014 05:23:00 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 974DA1AE038 for ; Tue, 7 Jan 2014 05:22:59 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s07DMne1014496 for ; Tue, 7 Jan 2014 14:22:49 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0114020571F for ; Tue, 7 Jan 2014 14:23:48 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id ECD16205705 for ; Tue, 7 Jan 2014 14:23:47 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s07DMb5e007724 for ; Tue, 7 Jan 2014 14:22:49 +0100 Message-ID: <52CBFF9D.5070301@gmail.com> Date: Tue, 07 Jan 2014 14:22:37 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] References: <52C9D788.8060606@gmail.com> <2134F8430051B64F815C691A62D9831818E598@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831818E598@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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, 07 Jan 2014 13:23:02 -0000 Le 06/01/2014 17:07, Templin, Fred L a écrit : > Hello Brian and co-authors, > > The draft looks good to me. In Section 3, paragraph 3, please > add ISATAP [RFC5214] and AERO [I-D.templin-aerolink] to the > list of "IPv6-over-foo" documents. Hi Fred, Yes, IID of ISATAP RFC5214 reads as fixed 64bit long, and should be cited. However, I am not sure ISATAP would apply to be an 'IPv6-over-foo' document. Rather a v4-v6 transition mechanism? If yes we have this text that could be augmented with ISATAP reference: > IPv6 transition mechanisms such as NAT64 and NPTv6, as well as Basic > transition and Teredo rely on the use of IIDs of length 64. On another hand, draft-templin-aerolink-00.txt seems to be an IPv6-over-foo document. I need to read this part more to better understand the suggestion. I will come back. Thanks for the suggestion. Alex > > Thanks - Fred > fred.l.templin@boeing.com > >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter >> Sent: Sunday, January 05, 2014 2:07 PM >> To: 6man >> Subject: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] >> >> Hi, >> >> A group of us put this together following a discussion some weeks >> ago on the v6ops list about the 64-bit boundary in IPv6 addresses. >> Discussion belongs in 6man, please. >> >> This draft is incomplete but we'd welcome input. Let me underline >> an important comment in the introduction: >> >> _The purpose of this document is to analyse the issues around this >> question. We make no proposal for change, but we do analyse the >> possible effects of a change._ >> >> >> Brian + co-authors >> >> -------- Original Message -------- >> Subject: I-D Action: draft-carpenter-6man-why64-00.txt >> Date: Sun, 05 Jan 2014 13:59:17 -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-00.txt >> Pages : 14 >> Date : 2014-01-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-00 >> >> >> >> >> >> >> >> >> >> -------------------------------------------------------------------- >> 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 Fred.L.Templin@boeing.com Tue Jan 7 07:59: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 443DE1ADF72 for ; Tue, 7 Jan 2014 07:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 ExIqQgne_eF2 for ; Tue, 7 Jan 2014 07:59:51 -0800 (PST) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id A41421ADF38 for ; Tue, 7 Jan 2014 07:59:51 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s07Fxgwd018528; Tue, 7 Jan 2014 07:59:42 -0800 Received: from XCH-PHX-511.sw.nos.boeing.com (xch-phx-511.sw.nos.boeing.com [10.57.37.28]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s07Fxc7D018452 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 7 Jan 2014 07:59:39 -0800 Received: from XCH-BLV-408.nw.nos.boeing.com (130.247.25.166) by XCH-PHX-511.sw.nos.boeing.com (10.57.37.28) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 7 Jan 2014 07:59:38 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-BLV-408.nw.nos.boeing.com ([169.254.8.217]) with mapi id 14.03.0158.001; Tue, 7 Jan 2014 07:59:37 -0800 From: "Templin, Fred L" To: Alexandru Petrescu , "ipv6@ietf.org" Subject: RE: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] Thread-Topic: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] Thread-Index: AQHPC6uIHEKzqaIg8UualVdPQhn+uJp5aMZQ Date: Tue, 7 Jan 2014 15:59:36 +0000 Message-ID: <2134F8430051B64F815C691A62D98318190FC1@XCH-BLV-504.nw.nos.boeing.com> References: <52C9D788.8060606@gmail.com> <2134F8430051B64F815C691A62D9831818E598@XCH-BLV-504.nw.nos.boeing.com> <52CBFF9D.5070301@gmail.com> In-Reply-To: <52CBFF9D.5070301@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable 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, 07 Jan 2014 15:59:53 -0000 Hi Alex, > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: Tuesday, January 07, 2014 5:23 AM > To: ipv6@ietf.org > Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] >=20 > Le 06/01/2014 17:07, Templin, Fred L a =E9crit : > > Hello Brian and co-authors, > > > > The draft looks good to me. In Section 3, paragraph 3, please > > add ISATAP [RFC5214] and AERO [I-D.templin-aerolink] to the > > list of "IPv6-over-foo" documents. >=20 > Hi Fred, >=20 > Yes, IID of ISATAP RFC5214 reads as fixed 64bit long, and should be cited= . >=20 > However, I am not sure ISATAP would apply to be an 'IPv6-over-foo' ISATAP specifies the formation of IPv6 interface identifiers and the operation of IPv6 neighbor discovery over a link type that supports the transmission of IPv6 packets, so it fits the description of IPv6 over (foo). > document. Rather a v4-v6 transition mechanism? Some sites that deploy ISATAP may find the service acceptable to the point that they never have to take it down and move onto native IPv6. I think that's part of the reason why there is so much teeth-gnashing among the haters who have pushed back on ISATAP over the years. > If yes we have this > text that could be augmented with ISATAP reference: > > IPv6 transition mechanisms such as NAT64 and NPTv6, as well as Basic > > transition and Teredo rely on the use of IIDs of length 64. >=20 > On another hand, draft-templin-aerolink-00.txt seems to be an > IPv6-over-foo document. I need to read this part more to better > understand the suggestion. I will come back. OK - thanks. Fred fred.l.templin@boeing.com > Thanks for the suggestion. >=20 > Alex >=20 > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> -----Original Message----- > >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpent= er > >> Sent: Sunday, January 05, 2014 2:07 PM > >> To: 6man > >> Subject: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] > >> > >> Hi, > >> > >> A group of us put this together following a discussion some weeks > >> ago on the v6ops list about the 64-bit boundary in IPv6 addresses. > >> Discussion belongs in 6man, please. > >> > >> This draft is incomplete but we'd welcome input. Let me underline > >> an important comment in the introduction: > >> > >> _The purpose of this document is to analyse the issues around this > >> question. We make no proposal for change, but we do analyse the > >> possible effects of a change._ > >> > >> > >> Brian + co-authors > >> > >> -------- Original Message -------- > >> Subject: I-D Action: draft-carpenter-6man-why64-00.txt > >> Date: Sun, 05 Jan 2014 13:59:17 -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 dir= ectories. > >> > >> > >> Title : Analysis of the 64-bit Boundary in IPv6 Add= ressing > >> Authors : Brian Carpenter > >> Tim Chown > >> Fernando Gont > >> Sheng Jiang > >> Alexandru Petrescu > >> Andrew Yourtchenko > >> Filename : draft-carpenter-6man-why64-00.txt > >> Pages : 14 > >> Date : 2014-01-05 > >> > >> Abstract: > >> The IPv6 unicast addressing format includes a separation between t= he > >> prefix used to route packets to a subnet and the interface identif= ier > >> 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 treatin= g > >> 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-00 > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From alexandru.petrescu@gmail.com Tue Jan 7 08:58: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 100AB1ADFA0 for ; Tue, 7 Jan 2014 08:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, 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 aPN743VXH33Z for ; Tue, 7 Jan 2014 08:58:44 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 813AB1ADFF8 for ; Tue, 7 Jan 2014 08:58:43 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s07GwUho011239; Tue, 7 Jan 2014 17:58:30 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3C67C205A97; Tue, 7 Jan 2014 17:59:28 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2F762205A0F; Tue, 7 Jan 2014 17:59:28 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s07GwQvU016709; Tue, 7 Jan 2014 17:58:29 +0100 Message-ID: <52CC3232.2030307@gmail.com> Date: Tue, 07 Jan 2014 17:58:26 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Templin, Fred L" , "ipv6@ietf.org" Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] References: <52C9D788.8060606@gmail.com> <2134F8430051B64F815C691A62D9831818E598@XCH-BLV-504.nw.nos.boeing.com> <52CBFF9D.5070301@gmail.com> <2134F8430051B64F815C691A62D98318190FC1@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D98318190FC1@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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, 07 Jan 2014 16:58:46 -0000 Hi Fred, Le 07/01/2014 16:59, Templin, Fred L a écrit : > Hi Alex, > >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Tuesday, January 07, 2014 5:23 AM >> To: ipv6@ietf.org >> Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] >> >> Le 06/01/2014 17:07, Templin, Fred L a écrit : >>> Hello Brian and co-authors, >>> >>> The draft looks good to me. In Section 3, paragraph 3, please >>> add ISATAP [RFC5214] and AERO [I-D.templin-aerolink] to the >>> list of "IPv6-over-foo" documents. >> >> Hi Fred, >> >> Yes, IID of ISATAP RFC5214 reads as fixed 64bit long, and should be cited. >> >> However, I am not sure ISATAP would apply to be an 'IPv6-over-foo' > > ISATAP specifies the formation of IPv6 interface identifiers and the > operation of IPv6 neighbor discovery over a link type that supports > the transmission of IPv6 packets, so it fits the description of IPv6 > over (foo). Sounds more like the IPv6-over-PPP part of the IP-over-foo family, in that PPP like ISATAP link layer is a sort of a dummy virtual link. (a more real IP-over-foo document would have e.g. a particular PHY). Let's see where we'll put this reference. >> document. Rather a v4-v6 transition mechanism? > > Some sites that deploy ISATAP may find the service acceptable to the > point that they never have to take it down and move onto native IPv6. > I think that's part of the reason why there is so much teeth-gnashing > among the haters who have pushed back on ISATAP over the years. > >> If yes we have this >> text that could be augmented with ISATAP reference: >>> IPv6 transition mechanisms such as NAT64 and NPTv6, as well as Basic >>> transition and Teredo rely on the use of IIDs of length 64. >> >> On another hand, draft-templin-aerolink-00.txt seems to be an >> IPv6-over-foo document. I need to read this part more to better >> understand the suggestion. I will come back. > > OK - thanks. Ok, let's see. Alex > > Fred > fred.l.templin@boeing.com > >> Thanks for the suggestion. >> >> Alex >> >>> >>> Thanks - Fred >>> fred.l.templin@boeing.com >>> >>>> -----Original Message----- >>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter >>>> Sent: Sunday, January 05, 2014 2:07 PM >>>> To: 6man >>>> Subject: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] >>>> >>>> Hi, >>>> >>>> A group of us put this together following a discussion some weeks >>>> ago on the v6ops list about the 64-bit boundary in IPv6 addresses. >>>> Discussion belongs in 6man, please. >>>> >>>> This draft is incomplete but we'd welcome input. Let me underline >>>> an important comment in the introduction: >>>> >>>> _The purpose of this document is to analyse the issues around this >>>> question. We make no proposal for change, but we do analyse the >>>> possible effects of a change._ >>>> >>>> >>>> Brian + co-authors >>>> >>>> -------- Original Message -------- >>>> Subject: I-D Action: draft-carpenter-6man-why64-00.txt >>>> Date: Sun, 05 Jan 2014 13:59:17 -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-00.txt >>>> Pages : 14 >>>> Date : 2014-01-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-00 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >>> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > From Fred.L.Templin@boeing.com Tue Jan 7 09:11: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 6781A1ADFF8 for ; Tue, 7 Jan 2014 09:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 5LigNmx33LAE for ; Tue, 7 Jan 2014 09:11:18 -0800 (PST) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 56D4B1AE04F for ; Tue, 7 Jan 2014 09:11:18 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s07HB8iL015483; Tue, 7 Jan 2014 11:11:09 -0600 Received: from XCH-PHX-411.sw.nos.boeing.com (xch-phx-411.sw.nos.boeing.com [10.57.37.42]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s07HAxpi014892 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 7 Jan 2014 11:11:00 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-PHX-411.sw.nos.boeing.com ([169.254.11.213]) with mapi id 14.03.0158.001; Tue, 7 Jan 2014 09:10:59 -0800 From: "Templin, Fred L" To: Alexandru Petrescu , "ipv6@ietf.org" Subject: RE: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] Thread-Topic: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] Thread-Index: AQHPC8muHEKzqaIg8UualVdPQhn+uJp5fRMQ Date: Tue, 7 Jan 2014 17:10:58 +0000 Message-ID: <2134F8430051B64F815C691A62D98318191143@XCH-BLV-504.nw.nos.boeing.com> References: <52C9D788.8060606@gmail.com> <2134F8430051B64F815C691A62D9831818E598@XCH-BLV-504.nw.nos.boeing.com> <52CBFF9D.5070301@gmail.com> <2134F8430051B64F815C691A62D98318190FC1@XCH-BLV-504.nw.nos.boeing.com> <52CC3232.2030307@gmail.com> In-Reply-To: <52CC3232.2030307@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable 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, 07 Jan 2014 17:11:21 -0000 Hi Alex, > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Tuesday, January 07, 2014 8:58 AM > To: Templin, Fred L; ipv6@ietf.org > Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] >=20 > Hi Fred, >=20 > Le 07/01/2014 16:59, Templin, Fred L a =E9crit : > > Hi Alex, > > > >> -----Original Message----- > >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Alexandru Petre= scu > >> Sent: Tuesday, January 07, 2014 5:23 AM > >> To: ipv6@ietf.org > >> Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] > >> > >> Le 06/01/2014 17:07, Templin, Fred L a =E9crit : > >>> Hello Brian and co-authors, > >>> > >>> The draft looks good to me. In Section 3, paragraph 3, please > >>> add ISATAP [RFC5214] and AERO [I-D.templin-aerolink] to the > >>> list of "IPv6-over-foo" documents. > >> > >> Hi Fred, > >> > >> Yes, IID of ISATAP RFC5214 reads as fixed 64bit long, and should be ci= ted. > >> > >> However, I am not sure ISATAP would apply to be an 'IPv6-over-foo' > > > > ISATAP specifies the formation of IPv6 interface identifiers and the > > operation of IPv6 neighbor discovery over a link type that supports > > the transmission of IPv6 packets, so it fits the description of IPv6 > > over (foo). >=20 > Sounds more like the IPv6-over-PPP part of the IP-over-foo family, in > that PPP like ISATAP link layer is a sort of a dummy virtual link. RFC4861 says: "Unless specified otherwise (in a document that covers operating IP over a particular link type) this document applies to all link types. However, because ND uses link-layer multicast for some of its services, it is possible that on some link types (e.g., Non-Broadcast Multi-Access (NBMA) links), alternative protocols or mechanisms to implement those services will be specified (in the appropriate document covering the operation of IP over a particular link type). The services described in this document that are not directly dependent on multicast, such as Redirects, Next-hop determination, Neighbor Unreachability Detection, etc., are expected to be provided as specified in this document. The details of how one uses ND on NBMA links are addressed in [IPv6-NBMA]. In addition, [IPv6-3GPP] and[IPv6-CELL] discuss the use of this protocol over some cellular links, which are examples of NBMA links." ISATAP is a document that covers operating IP over a particular link type. ISATAP links are NBMA, and ISATAP specifies the operation of IPv6 ND over that link type. > (a more real IP-over-foo document would have e.g. a particular PHY). ISATAP links are very real; the PHY is the underlying IPv4 site. Thanks - Fred fred.l.templin@boeing.com > Let's see where we'll put this reference. >=20 > >> document. Rather a v4-v6 transition mechanism? > > > > Some sites that deploy ISATAP may find the service acceptable to the > > point that they never have to take it down and move onto native IPv6. > > I think that's part of the reason why there is so much teeth-gnashing > > among the haters who have pushed back on ISATAP over the years. > > > >> If yes we have this > >> text that could be augmented with ISATAP reference: > >>> IPv6 transition mechanisms such as NAT64 and NPTv6, as well as Ba= sic > >>> transition and Teredo rely on the use of IIDs of length 64. > >> > >> On another hand, draft-templin-aerolink-00.txt seems to be an > >> IPv6-over-foo document. I need to read this part more to better > >> understand the suggestion. I will come back. > > > > OK - thanks. >=20 > Ok, let's see. >=20 > Alex >=20 > > > > Fred > > fred.l.templin@boeing.com > > > >> Thanks for the suggestion. > >> > >> Alex > >> > >>> > >>> Thanks - Fred > >>> fred.l.templin@boeing.com > >>> > >>>> -----Original Message----- > >>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpe= nter > >>>> Sent: Sunday, January 05, 2014 2:07 PM > >>>> To: 6man > >>>> Subject: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] > >>>> > >>>> Hi, > >>>> > >>>> A group of us put this together following a discussion some weeks > >>>> ago on the v6ops list about the 64-bit boundary in IPv6 addresses. > >>>> Discussion belongs in 6man, please. > >>>> > >>>> This draft is incomplete but we'd welcome input. Let me underline > >>>> an important comment in the introduction: > >>>> > >>>> _The purpose of this document is to analyse the issues around th= is > >>>> question. We make no proposal for change, but we do analyse th= e > >>>> possible effects of a change._ > >>>> > >>>> > >>>> Brian + co-authors > >>>> > >>>> -------- Original Message -------- > >>>> Subject: I-D Action: draft-carpenter-6man-why64-00.txt > >>>> Date: Sun, 05 Jan 2014 13:59:17 -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 d= irectories. > >>>> > >>>> > >>>> 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-00.txt > >>>> Pages : 14 > >>>> Date : 2014-01-05 > >>>> > >>>> Abstract: > >>>> The IPv6 unicast addressing format includes a separation betwee= n the > >>>> prefix used to route packets to a subnet and the interface iden= tifier > >>>> used to specify a given interface connected to that subnet. > >>>> Historically the interface identifier has been defined as 64 bi= ts > >>>> long, leaving 64 bits for the prefix. This document discusses = the > >>>> reasons for this fixed boundary and the issues involved in trea= ting > >>>> 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-00 > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -------------------------------------------------------------------- > >>>> IETF IPv6 working group mailing list > >>>> ipv6@ietf.org > >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>>> -------------------------------------------------------------------- > >>> -------------------------------------------------------------------- > >>> IETF IPv6 working group mailing list > >>> ipv6@ietf.org > >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>> -------------------------------------------------------------------- > >>> > >>> > >> > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > > > >=20 From alexandru.petrescu@gmail.com Tue Jan 7 09:45:35 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 945591AE097 for ; Tue, 7 Jan 2014 09:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, 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 ep3ItAOF_SfG for ; Tue, 7 Jan 2014 09:45:32 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 578BA1AE093 for ; Tue, 7 Jan 2014 09:45:32 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s07HjJ5V004092; Tue, 7 Jan 2014 18:45:19 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7F3F5205ACB; Tue, 7 Jan 2014 18:46:17 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 73CBA205A7B; Tue, 7 Jan 2014 18:46:17 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s07HjIVW008517; Tue, 7 Jan 2014 18:45:19 +0100 Message-ID: <52CC3D2E.8040005@gmail.com> Date: Tue, 07 Jan 2014 18:45:18 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Templin, Fred L" , "ipv6@ietf.org" Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] References: <52C9D788.8060606@gmail.com> <2134F8430051B64F815C691A62D9831818E598@XCH-BLV-504.nw.nos.boeing.com> <52CBFF9D.5070301@gmail.com> <2134F8430051B64F815C691A62D98318190FC1@XCH-BLV-504.nw.nos.boeing.com> <52CC3232.2030307@gmail.com> <2134F8430051B64F815C691A62D98318191143@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D98318191143@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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, 07 Jan 2014 17:45:35 -0000 Le 07/01/2014 18:10, Templin, Fred L a écrit : > Hi Alex, > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Tuesday, January 07, 2014 8:58 AM >> To: Templin, Fred L; ipv6@ietf.org >> Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] >> >> Hi Fred, >> >> Le 07/01/2014 16:59, Templin, Fred L a écrit : >>> Hi Alex, >>> >>>> -----Original Message----- >>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>>> Sent: Tuesday, January 07, 2014 5:23 AM >>>> To: ipv6@ietf.org >>>> Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] >>>> >>>> Le 06/01/2014 17:07, Templin, Fred L a écrit : >>>>> Hello Brian and co-authors, >>>>> >>>>> The draft looks good to me. In Section 3, paragraph 3, please >>>>> add ISATAP [RFC5214] and AERO [I-D.templin-aerolink] to the >>>>> list of "IPv6-over-foo" documents. >>>> >>>> Hi Fred, >>>> >>>> Yes, IID of ISATAP RFC5214 reads as fixed 64bit long, and should be cited. >>>> >>>> However, I am not sure ISATAP would apply to be an 'IPv6-over-foo' >>> >>> ISATAP specifies the formation of IPv6 interface identifiers and the >>> operation of IPv6 neighbor discovery over a link type that supports >>> the transmission of IPv6 packets, so it fits the description of IPv6 >>> over (foo). >> >> Sounds more like the IPv6-over-PPP part of the IP-over-foo family, in >> that PPP like ISATAP link layer is a sort of a dummy virtual link. > > RFC4861 says: > > "Unless specified otherwise (in a document that covers operating IP > over a particular link type) this document applies to all link types. > However, because ND uses link-layer multicast for some of its > services, it is possible that on some link types (e.g., Non-Broadcast > Multi-Access (NBMA) links), alternative protocols or mechanisms to > implement those services will be specified (in the appropriate > document covering the operation of IP over a particular link type). > The services described in this document that are not directly > dependent on multicast, such as Redirects, Next-hop determination, > Neighbor Unreachability Detection, etc., are expected to be provided > as specified in this document. The details of how one uses ND on > NBMA links are addressed in [IPv6-NBMA]. In addition, [IPv6-3GPP] > and[IPv6-CELL] discuss the use of this protocol over some cellular > links, which are examples of NBMA links." > > ISATAP is a document that covers operating IP over a particular link > type. ISATAP links are NBMA, and ISATAP specifies the operation of > IPv6 ND over that link type. > >> (a more real IP-over-foo document would have e.g. a particular PHY). > > ISATAP links are very real; the PHY is the underlying IPv4 site. I don't doubt ISATAP links are real links which transport real packets. But a PHY would have a specific encoding scheme (OFDM, TDMA, etc.), which IPV4 had not. Alex > > Thanks - Fred > fred.l.templin@boeing.com > >> Let's see where we'll put this reference. >> >>>> document. Rather a v4-v6 transition mechanism? >>> >>> Some sites that deploy ISATAP may find the service acceptable to the >>> point that they never have to take it down and move onto native IPv6. >>> I think that's part of the reason why there is so much teeth-gnashing >>> among the haters who have pushed back on ISATAP over the years. >>> >>>> If yes we have this >>>> text that could be augmented with ISATAP reference: >>>>> IPv6 transition mechanisms such as NAT64 and NPTv6, as well as Basic >>>>> transition and Teredo rely on the use of IIDs of length 64. >>>> >>>> On another hand, draft-templin-aerolink-00.txt seems to be an >>>> IPv6-over-foo document. I need to read this part more to better >>>> understand the suggestion. I will come back. >>> >>> OK - thanks. >> >> Ok, let's see. >> >> Alex >> >>> >>> Fred >>> fred.l.templin@boeing.com >>> >>>> Thanks for the suggestion. >>>> >>>> Alex >>>> >>>>> >>>>> Thanks - Fred >>>>> fred.l.templin@boeing.com >>>>> >>>>>> -----Original Message----- >>>>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter >>>>>> Sent: Sunday, January 05, 2014 2:07 PM >>>>>> To: 6man >>>>>> Subject: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] >>>>>> >>>>>> Hi, >>>>>> >>>>>> A group of us put this together following a discussion some weeks >>>>>> ago on the v6ops list about the 64-bit boundary in IPv6 addresses. >>>>>> Discussion belongs in 6man, please. >>>>>> >>>>>> This draft is incomplete but we'd welcome input. Let me underline >>>>>> an important comment in the introduction: >>>>>> >>>>>> _The purpose of this document is to analyse the issues around this >>>>>> question. We make no proposal for change, but we do analyse the >>>>>> possible effects of a change._ >>>>>> >>>>>> >>>>>> Brian + co-authors >>>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: I-D Action: draft-carpenter-6man-why64-00.txt >>>>>> Date: Sun, 05 Jan 2014 13:59:17 -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-00.txt >>>>>> Pages : 14 >>>>>> Date : 2014-01-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-00 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -------------------------------------------------------------------- >>>>>> IETF IPv6 working group mailing list >>>>>> ipv6@ietf.org >>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>> -------------------------------------------------------------------- >>>>> -------------------------------------------------------------------- >>>>> IETF IPv6 working group mailing list >>>>> ipv6@ietf.org >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>> -------------------------------------------------------------------- >>>>> >>>>> >>>> >>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>> >>> >> > > From Fred.L.Templin@boeing.com Tue Jan 7 09:50: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 6A59F1AE0C0 for ; Tue, 7 Jan 2014 09:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 kWhf0QggxWge for ; Tue, 7 Jan 2014 09:50:06 -0800 (PST) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 671151AE097 for ; Tue, 7 Jan 2014 09:50:06 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s07HnvI2030867; Tue, 7 Jan 2014 09:49:57 -0800 Received: from XCH-PHX-509.sw.nos.boeing.com (xch-phx-509.sw.nos.boeing.com [10.57.37.31]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s07Hnn4C030757 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 7 Jan 2014 09:49:50 -0800 Received: from XCH-EXCO-104.nw.nos.boeing.com (130.247.204.53) by XCH-PHX-509.sw.nos.boeing.com (10.57.37.31) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 7 Jan 2014 09:49:49 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-EXCO-104.nw.nos.boeing.com ([169.254.5.243]) with mapi id 14.03.0158.001; Tue, 7 Jan 2014 11:49:48 -0600 From: "Templin, Fred L" To: Alexandru Petrescu , "ipv6@ietf.org" Subject: RE: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] Thread-Topic: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] Thread-Index: AQHPC9A6HEKzqaIg8UualVdPQhn+uJp5iQBg Date: Tue, 7 Jan 2014 17:49:46 +0000 Message-ID: <2134F8430051B64F815C691A62D983181911CF@XCH-BLV-504.nw.nos.boeing.com> References: <52C9D788.8060606@gmail.com> <2134F8430051B64F815C691A62D9831818E598@XCH-BLV-504.nw.nos.boeing.com> <52CBFF9D.5070301@gmail.com> <2134F8430051B64F815C691A62D98318190FC1@XCH-BLV-504.nw.nos.boeing.com> <52CC3232.2030307@gmail.com> <2134F8430051B64F815C691A62D98318191143@XCH-BLV-504.nw.nos.boeing.com> <52CC3D2E.8040005@gmail.com> In-Reply-To: <52CC3D2E.8040005@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.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, 07 Jan 2014 17:50:07 -0000 Hi Alex, > > ISATAP links are very real; the PHY is the underlying IPv4 site. >=20 > I don't doubt ISATAP links are real links which transport real packets. >=20 > But a PHY would have a specific encoding scheme (OFDM, TDMA, etc.), > which IPV4 had not. That doesn't matter. What matters is that ISATAP (like AERO) specifies the generation of IPv6 interface identifiers which are 64-bits in length - which is exactly the subject your document is addressing. Thanks - Fred fred.l.templin@boeing.com From brian.e.carpenter@gmail.com Tue Jan 7 11:22: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 5AB581AE13B for ; Tue, 7 Jan 2014 11:22:33 -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 2-U90AbcXQst for ; Tue, 7 Jan 2014 11:22:31 -0800 (PST) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3581AE139 for ; Tue, 7 Jan 2014 11:22:31 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id um1so524963pbc.6 for ; Tue, 07 Jan 2014 11:22: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=ydJCd10H+0IwT+pZjqpXa0zMB7A83kWL+My3l6TYIpg=; b=BCAV8f4um6otnboBWr2aOVX98flY0H0dvMF7xJ0Z1/GK0sAqUpwx2zX8bywCNXvQ+k sglG3itdu2bk2OlRGYyHaap8kF3NcR0KIx6LKkzHIL2rrvSSrNQFSlGoyd0VpjYT/GzQ FIxUbJ9hMM8cJuYKSjWv6pJf6SQMyAHhGksnNS9gkYD8232b1iabVhCKUPjNBf2XEqu+ SOjv48oKj1I+y3Q7CPxQrydxBb1700H5p+b4X7HpoKL85PFaGOn7mQuBkoxWNEJ2Am6F LChpBFdeFolCSLYg4P5MLrtCMDn0D5PhlK4TFkKI76kijo/fmiLCuxjFPfGUNNTlFSN5 vQSQ== X-Received: by 10.68.232.132 with SMTP id to4mr17596161pbc.141.1389122542739; Tue, 07 Jan 2014 11:22:22 -0800 (PST) Received: from [192.168.178.21] (217.194.69.111.dynamic.snap.net.nz. [111.69.194.217]) by mx.google.com with ESMTPSA id jp3sm12946199pbc.36.2014.01.07.11.22.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Jan 2014 11:22:22 -0800 (PST) Message-ID: <52CC53F2.20802@gmail.com> Date: Wed, 08 Jan 2014 08:22:26 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] References: <52C9D788.8060606@gmail.com> <2134F8430051B64F815C691A62D9831818E598@XCH-BLV-504.nw.nos.boeing.com> <52CBFF9D.5070301@gmail.com> <2134F8430051B64F815C691A62D98318190FC1@XCH-BLV-504.nw.nos.boeing.com> <52CC3232.2030307@gmail.com> <2134F8430051B64F815C691A62D98318191143@XCH-BLV-504.nw.nos.boeing.com> <52CC3D2E.8040005@gmail.com> <2134F8430051B64F815C691A62D983181911CF@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983181911CF@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alexandru Petrescu , "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, 07 Jan 2014 19:22:33 -0000 On 08/01/2014 06:49, Templin, Fred L wrote: > Hi Alex, > >>> ISATAP links are very real; the PHY is the underlying IPv4 site. >> I don't doubt ISATAP links are real links which transport real packets. >> >> But a PHY would have a specific encoding scheme (OFDM, TDMA, etc.), >> which IPV4 had not. > > That doesn't matter. What matters is that ISATAP (like AERO) specifies > the generation of IPv6 interface identifiers which are 64-bits in > length - which is exactly the subject your document is addressing. I agree with Fred. Actually for completeness we should list RFC 2529 (6over4) too, although it is unused today as far as I know. Brian From brian.e.carpenter@gmail.com Tue Jan 7 11:32: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 5869B1AE14D for ; Tue, 7 Jan 2014 11:32: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 Mv1M1TWRQ8SU for ; Tue, 7 Jan 2014 11:32:36 -0800 (PST) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id E8AC81AE141 for ; Tue, 7 Jan 2014 11:32:35 -0800 (PST) Received: by mail-pd0-f178.google.com with SMTP id y10so756922pdj.23 for ; Tue, 07 Jan 2014 11:32:27 -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=WE/+YN5wRZ4g/a91toqIzxRg7sfnropoAxtnnLR+njw=; b=q+W2qTA1oXbM93PNXBQfItDLcYdOhhC4WuC5ACDsgk8MFItL0NBaWJS5ds3npAZgoj dttGZBCiCOXZ/Gk3nwBJvbdLEwcJWsMxeCCSBKboqAFaF+iEkpX8nZ9XWPOaE2DPT1xA Q5k2OhBEHYeRXA0XaIO59gzuWTtIcmkPwoueEkb4jqxsXi7d6B+15aMjinGzEyQdukqg SRJwi3dptncsBwsSY2q13BQhf8575jp54+AERJplmnqTTu93NvJ1skV1ToqJMAB43AmA Qnou2N5b0uvvp2X0JbNGH/+aiZQtD2B7FxXKMrX1AtSMGMT7TN8HdG071xYyJqpePRyP Q7PQ== X-Received: by 10.66.11.202 with SMTP id s10mr7562501pab.86.1389123146732; Tue, 07 Jan 2014 11:32:26 -0800 (PST) Received: from [192.168.178.21] (217.194.69.111.dynamic.snap.net.nz. [111.69.194.217]) by mx.google.com with ESMTPSA id zc6sm131176303pab.0.2014.01.07.11.32.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Jan 2014 11:32:25 -0800 (PST) Message-ID: <52CC564E.2070402@gmail.com> Date: Wed, 08 Jan 2014 08:32:30 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Hunter Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] References: <52C9D788.8060606@gmail.com> <52CBE0E6.5020107@globis.net> In-Reply-To: <52CBE0E6.5020107@globis.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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, 07 Jan 2014 19:32:38 -0000 Hi Ray, Thanks for the comments. On 08/01/2014 00:11, Ray Hunter wrote: ... > Where exactly is the requirement that IPv6 has to use /64 prefix length > really enshrined? I don't think it is enshrined in any one place; in fact at one level the architecture carefully avoids it. > I think the draft can help clarify that, and that alone makes it > worthwhile proceeding. > > > I humbly disagree with the conclusions in Section 9. > > The argument seems to assume that all n hosts must be allocated within > one single prefix with a prefix length >> 64. That is a very common deployment model, surely? I don't think the death of the L2 switch has been declared yet; I see plenty of them around. I agree that it *could* be done differently as you describe below. > Therefore it assumes that increasing prefix length reduces attack search > space (given some knowledge of one or more active IPv6 addresses) > > IMHO Address space is address space. Allocation density is allocation > density. IPv6 supports multiple prefixes per link and the concept of > determining "on link prefixes" via rfc5942 (unlike the "subnet mask" > mechanism of IPv4). > > It should be perfectly feasible to allocate a /64 to a router interface > in an IPAM tool, but then configure the equivalent of n prefixes each > containing 1 or 2 address with prefix length /128 or /127 (depending on > the implementation) for n hosts and which are equally sparsely assigned > across the /64, and all sharing a single L2 link. Even end node to end > node communication should flow directly (avoiding the router) as these > prefixes could be marked "on link" via the AdvOnLinkFlag = L flag. > > Anyway, in the majority of modern day wired deployments, the delta cost > of L3 over L2 is minimal, as the most dominant form of wired LAN > (Ethernet) are commonly switched in silicon, and multicast has to be > emulated. Wired Ethernet has in effect become a point to point protocol. > So deploying a dedicated L3 connection per end host is both technically > and financially feasible, and may have significant operational benefits > in certain scenarios. Allocating a /64 for each such port on a L3 switch > is sub optimal IMHO. And by the same privacy argument, allocating n > hosts sparsely over a single /64 of address space spread over multiple > L3 interfaces would have the same net effect for off-net attackers as n > hosts sharing a flat L2 LAN using a single /64, with the added advantage > that even locally the individual end nodes would not be able to > passively observe each other's traffic or addresses (advantageous in > shared hosting environments). > > An attacker that happens to discover the address of node A would not > find this information helpful in attempts to locate node B, any more > than if it were a flat /64. > > So to me it's a non-relevant argument one way or the other. > > Section 2.2 > > It may not be a widely held belief, but I remain concerned about the > potential for resource exhaustion for any number of processes due to the > "massive over sizing" of prefixes to /64: any number of untested > processes that track state based on /128 IPv6 address could be attacked. > The flip side of expanding privacy through address obfuscation at IID > level is that the source space available for attacks also increases. ND > cache exhaustion is probably just the first issue we've discovered of > many that exist. That is a bit of a vague argument to put in an RFC though. Can you find at least one example of such an attack? Brian > This may have knock on operational consequences, which > in the IPv4 world have relied on the scarcity of IPv4 address space to > be able to operate correctly under stress scenarios. We're going to > discover who has been swimming naked when the tide goes out. Call that > FUD, or operational expediency, whichever you like. BCP38 has saved me > on a number of occasions when all else has failed. > > From tjc@ecs.soton.ac.uk Tue Jan 7 11:36: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 C0BC81AE167 for ; Tue, 7 Jan 2014 11:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 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.538, SPF_NEUTRAL=0.779] 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 B_Cl2Rdpot2E for ; Tue, 7 Jan 2014 11:36:45 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBA81AE15F for ; Tue, 7 Jan 2014 11:36:45 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s07JaWFO002544; Tue, 7 Jan 2014 19:36:32 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s07JaWFO002544 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1389123392; bh=14eHPJMHs74/RFydH+tn0WUSk7k=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=eD9+aXbARqUAcp7zQoFeR8Gb9mbgxzXQ8EvL9iMbEXKIA53Ke18c2qnHd4zsKvwtM Mjh61/Ats+cBdxm87tpR0m9kDInH1YjUi7QcZMXFFyvK1KVnyqn/lXt/LZxQKP9GA6 73QU+7aW7CNPv9oCp73sajF+uBBLhXDtVPsFNvaU= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q06JaW0959634824Gz ret-id none; Tue, 07 Jan 2014 19:36:32 +0000 Received: from [192.168.1.101] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s07JZI7Z018038 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Jan 2014 19:36:04 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] From: Tim Chown In-Reply-To: <52CBE0E6.5020107@globis.net> Date: Tue, 7 Jan 2014 19:36:06 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <52C9D788.8060606@gmail.com> <52CBE0E6.5020107@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1827) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q06JaW095963482400; tid=q06JaW0959634824Gz; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s07JaWFO002544 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk 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, 07 Jan 2014 19:36:49 -0000 Hi Ray, It would be good to suggest specific text/edits. Tim On 7 Jan 2014, at 11:11, Ray Hunter wrote: > Brian E Carpenter wrote: >> Hi, >>=20 >> A group of us put this together following a discussion some weeks >> ago on the v6ops list about the 64-bit boundary in IPv6 addresses. >> Discussion belongs in 6man, please. >>=20 >> This draft is incomplete but we'd welcome input. Let me underline >> an important comment in the introduction: >>=20 >> _The purpose of this document is to analyse the issues around this >> question. We make no proposal for change, but we do analyse the >> possible effects of a change._ >>=20 >>=20 >> Brian + co-authors >>=20 >> -------- Original Message -------- >> Subject: I-D Action: draft-carpenter-6man-why64-00.txt >> Date: Sun, 05 Jan 2014 13:59:17 -0800 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >>=20 >> 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-00.txt >> Pages : 14 >> Date : 2014-01-05 >>=20 >> 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. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-carpenter-6man-why64/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-carpenter-6man-why64-00 >>=20 >>=20 > I have read this draft. >=20 > some comments: >=20 > Where exactly is the requirement that IPv6 has to use /64 prefix = length really enshrined? > I think the draft can help clarify that, and that alone makes it = worthwhile proceeding. >=20 >=20 > I humbly disagree with the conclusions in Section 9. >=20 > The argument seems to assume that all n hosts must be allocated within = one single prefix with a prefix length >> 64. > Therefore it assumes that increasing prefix length reduces attack = search space (given some knowledge of one or more active IPv6 addresses) >=20 > IMHO Address space is address space. Allocation density is allocation = density. IPv6 supports multiple prefixes per link and the concept of = determining "on link prefixes" via rfc5942 (unlike the "subnet mask" = mechanism of IPv4). >=20 > It should be perfectly feasible to allocate a /64 to a router = interface in an IPAM tool, but then configure the equivalent of n = prefixes each containing 1 or 2 address with prefix length /128 or /127 = (depending on the implementation) for n hosts and which are equally = sparsely assigned across the /64, and all sharing a single L2 link. Even = end node to end node communication should flow directly (avoiding the = router) as these prefixes could be marked "on link" via the = AdvOnLinkFlag =3D L flag. >=20 > Anyway, in the majority of modern day wired deployments, the delta = cost of L3 over L2 is minimal, as the most dominant form of wired LAN = (Ethernet) are commonly switched in silicon, and multicast has to be = emulated. Wired Ethernet has in effect become a point to point protocol. = So deploying a dedicated L3 connection per end host is both technically = and financially feasible, and may have significant operational benefits = in certain scenarios. Allocating a /64 for each such port on a L3 switch = is sub optimal IMHO. And by the same privacy argument, allocating n = hosts sparsely over a single /64 of address space spread over multiple = L3 interfaces would have the same net effect for off-net attackers as n = hosts sharing a flat L2 LAN using a single /64, with the added advantage = that even locally the individual end nodes would not be able to = passively observe each other's traffic or addresses (advantageous in = shared hosting environments). >=20 > An attacker that happens to discover the address of node A would not = find this information helpful in attempts to locate node B, any more = than if it were a flat /64. >=20 > So to me it's a non-relevant argument one way or the other. >=20 > Section 2.2 >=20 > It may not be a widely held belief, but I remain concerned about the = potential for resource exhaustion for any number of processes due to the = "massive over sizing" of prefixes to /64: any number of untested = processes that track state based on /128 IPv6 address could be attacked. = The flip side of expanding privacy through address obfuscation at IID = level is that the source space available for attacks also increases. ND = cache exhaustion is probably just the first issue we've discovered of = many that exist. This may have knock on operational consequences, which = in the IPv4 world have relied on the scarcity of IPv4 address space to = be able to operate correctly under stress scenarios. We're going to = discover who has been swimming naked when the tide goes out. Call that = FUD, or operational expediency, whichever you like. BCP38 has saved me = on a number of occasions when all else has failed. >=20 >=20 > --=20 > Regards, > RayH >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From tjc@ecs.soton.ac.uk Tue Jan 7 11:36: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 2D7A31AE16A for ; Tue, 7 Jan 2014 11:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 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.538, SPF_NEUTRAL=0.779] 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 bzdeQKA3sXXX for ; Tue, 7 Jan 2014 11:36:53 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE7D1AE166 for ; Tue, 7 Jan 2014 11:36:52 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s07Jaajn002577; Tue, 7 Jan 2014 19:36:36 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s07Jaajn002577 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1389123397; bh=lfCrSQcHTfxEtxmOdLosuU5QXYQ=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=iNXo+0PJz4bsDBJ/3JMU95RDq1cNNKNm3LAKYa1e+DORtCNBXQxHXDtUpnrx3DNAJ EZxo7WMXGRAMGkTVLfqKS8OJEW4KaEHQtFHh41g3EeGsHU5L97PgrRo1nFBuLJMrdV Dt2T0DB70+lhdrru/6Akr7e70BoZ6cYRZFi2kzCg= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id q06Jaa095963482576 ret-id none; Tue, 07 Jan 2014 19:36:37 +0000 Received: from [192.168.1.101] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s07JZI7Y018038 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Jan 2014 19:35:18 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] From: Tim Chown In-Reply-To: <52CC53F2.20802@gmail.com> Date: Tue, 7 Jan 2014 19:35:20 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <52C9D788.8060606@gmail.com> <2134F8430051B64F815C691A62D9831818E598@XCH-BLV-504.nw.nos.boeing.com> <52CBFF9D.5070301@gmail.com> <2134F8430051B64F815C691A62D98318190FC1@XCH-BLV-504.nw.nos.boeing.com> <52CC3232.2030307@gmail.com> <2134F8430051B64F815C691A62D98318191143@XCH-BLV-504.nw.nos.boeing.com> <52CC3D2E.8040005@gmail.com> <2134F8430051B64F815C691A62D983181911CF@XCH-BLV-504.nw.nos.boeing.com> <52CC53F2.20802@gmail.com> <6E0E91F1-AEB9-4815-95DD-A9D111D0A54D@ecs.soton.ac.uk> To: Brian E Carpenter X-Mailer: Apple Mail (2.1827) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q06Jaa095963482500; tid=q06Jaa095963482576; client=relay,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s07Jaajn002577 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "ipv6@ietf.org" , Alexandru Petrescu 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, 07 Jan 2014 19:36:55 -0000 On 7 Jan 2014, at 19:22, Brian E Carpenter = wrote: > On 08/01/2014 06:49, Templin, Fred L wrote: >> Hi Alex, >>=20 >>>> ISATAP links are very real; the PHY is the underlying IPv4 site. >>> I don't doubt ISATAP links are real links which transport real = packets. >>>=20 >>> But a PHY would have a specific encoding scheme (OFDM, TDMA, etc.), >>> which IPV4 had not. >>=20 >> That doesn't matter. What matters is that ISATAP (like AERO) = specifies >> the generation of IPv6 interface identifiers which are 64-bits in >> length - which is exactly the subject your document is addressing. >=20 > I agree with Fred. Actually for completeness we should list > RFC 2529 (6over4) too, although it is unused today as far as I know. Yeah, I thought this was a bit of a diversion, but I agree it=92s a = necessary rathole for completeness, whether anyone uses ISATAP or not. = Likewise 6over4. So I looked at some other transition tools. e.g. 6rd says (section 4 of = RFC5969) that =93a 6rd delegated prefix SHOULD be /64 or shorter=94. No = MUST, presumably for ISPs that for some reason just give a customer one = IPv6 address. For 6to4, section 2 of RFC3056 implies use of /64. Maybe = we can just have a short section listing what each mechanism says, where = at the moment I think we just have one sentence in section 3 ("IPv6 = transition mechanisms such as NAT64 and NPTv6, as well as Basic = transition and Teredo rely on the use of IIDs of length 64.=93) Tim= From Fred.L.Templin@boeing.com Tue Jan 7 11:55: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 E1B6C1AE15B for ; Tue, 7 Jan 2014 11:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 nbWdJpQBjSyN for ; Tue, 7 Jan 2014 11:54:59 -0800 (PST) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id AEE8E1ADF98 for ; Tue, 7 Jan 2014 11:54:59 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s07Jsogq001783; Tue, 7 Jan 2014 11:54:50 -0800 Received: from XCH-PHX-213.sw.nos.boeing.com (xch-phx-213.sw.nos.boeing.com [130.247.25.142]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s07Jsibq001720 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 7 Jan 2014 11:54:44 -0800 Received: from XCH-BLV-303.nw.nos.boeing.com (130.247.25.215) by XCH-PHX-213.sw.nos.boeing.com (130.247.25.142) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 7 Jan 2014 11:54:44 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-BLV-303.nw.nos.boeing.com ([169.254.3.44]) with mapi id 14.03.0158.001; Tue, 7 Jan 2014 11:54:44 -0800 From: "Templin, Fred L" To: Tim Chown , Brian E Carpenter Subject: RE: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] Thread-Topic: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] Thread-Index: AQHPC9+ZHEKzqaIg8UualVdPQhn+uJp5qxKw Date: Tue, 7 Jan 2014 19:54:42 +0000 Message-ID: <2134F8430051B64F815C691A62D9831819141F@XCH-BLV-504.nw.nos.boeing.com> References: <52C9D788.8060606@gmail.com> <2134F8430051B64F815C691A62D9831818E598@XCH-BLV-504.nw.nos.boeing.com> <52CBFF9D.5070301@gmail.com> <2134F8430051B64F815C691A62D98318190FC1@XCH-BLV-504.nw.nos.boeing.com> <52CC3232.2030307@gmail.com> <2134F8430051B64F815C691A62D98318191143@XCH-BLV-504.nw.nos.boeing.com> <52CC3D2E.8040005@gmail.com> <2134F8430051B64F815C691A62D983181911CF@XCH-BLV-504.nw.nos.boeing.com> <52CC53F2.20802@gmail.com> <6E0E91F1-AEB9-4815-95DD-A9D111D0A54D@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: Alexandru Petrescu , "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, 07 Jan 2014 19:55:01 -0000 Hi Tim, > -----Original Message----- > From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] > Sent: Tuesday, January 07, 2014 11:35 AM > To: Brian E Carpenter > Cc: Templin, Fred L; Alexandru Petrescu; ipv6@ietf.org > Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] >=20 > On 7 Jan 2014, at 19:22, Brian E Carpenter = wrote: >=20 > > On 08/01/2014 06:49, Templin, Fred L wrote: > >> Hi Alex, > >> > >>>> ISATAP links are very real; the PHY is the underlying IPv4 site. > >>> I don't doubt ISATAP links are real links which transport real packet= s. > >>> > >>> But a PHY would have a specific encoding scheme (OFDM, TDMA, etc.), > >>> which IPV4 had not. > >> > >> That doesn't matter. What matters is that ISATAP (like AERO) specifies > >> the generation of IPv6 interface identifiers which are 64-bits in > >> length - which is exactly the subject your document is addressing. > > > > I agree with Fred. Actually for completeness we should list > > RFC 2529 (6over4) too, although it is unused today as far as I know. >=20 > Yeah, I thought this was a bit of a diversion, but I agree it's a necessa= ry rathole for completeness, > whether anyone uses ISATAP or not. Likewise 6over4. Thanks, but please don't forget that ISATAP (and AERO and 6over4) are IPv6-over-(foo) documents in that they specify the IPv6 interface identifier format and the operation of IPv6 ND over specific link layers (which as Alex agreed are real links which transport real packets). Thanks - Fred fred.l.templin@boeing.com > So I looked at some other transition tools. e.g. 6rd says (section 4 of = RFC5969) that "a 6rd > delegated prefix SHOULD be /64 or shorter". No MUST, presumably for ISPs= that for some reason just > give a customer one IPv6 address. For 6to4, section 2 of RFC3056 implies= use of /64. Maybe we can > just have a short section listing what each mechanism says, where at the = moment I think we just have > one sentence in section 3 ("IPv6 transition mechanisms such as NAT64 and = NPTv6, as well as Basic > transition and Teredo rely on the use of IIDs of length 64.") >=20 > Tim From ietf-secretariat-reply@ietf.org Tue Jan 7 12:15: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 1A0B31AE167 for ; Tue, 7 Jan 2014 12:15:32 -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 qeORkF0wzzHH for ; Tue, 7 Jan 2014 12:15:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD3D1AE187 for ; Tue, 7 Jan 2014 12:15:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: ipv6@ietf.org Subject: Milestones changed for 6man WG X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140107201529.21062.82432.idtracker@ietfa.amsl.com> Date: Tue, 07 Jan 2014 12:15:29 -0800 From: IETF Secretariat 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: Tue, 07 Jan 2014 20:15:32 -0000 Changed milestone "Determine way forward for ULA-C specification", resolved as "Done". Changed milestone "Resolve open issues with "U/G" bits in Interface Identifiers", resolved as "Done". URL: http://datatracker.ietf.org/wg/6man/charter/ From ietf-secretariat-reply@ietf.org Tue Jan 7 12:18: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 764C51AE167 for ; Tue, 7 Jan 2014 12:18:15 -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 iXaklZsfyw4j for ; Tue, 7 Jan 2014 12:18:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1AAD1AE19C for ; Tue, 7 Jan 2014 12:18:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: ipv6@ietf.org Subject: Milestones changed for 6man WG X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140107201812.13065.53114.idtracker@ietfa.amsl.com> Date: Tue, 07 Jan 2014 12:18:12 -0800 From: IETF Secretariat 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: Tue, 07 Jan 2014 20:18:15 -0000 Changed milestone "Submit PPP Compression Negotiation specification to IESG as a Proposed Standard", resolved as "Done". URL: http://datatracker.ietf.org/wg/6man/charter/ From samita.chakrabarti@ericsson.com Tue Jan 7 12: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 0F6A81AE17E for ; Tue, 7 Jan 2014 12: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_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 tEQJjbOGG9wu for ; Tue, 7 Jan 2014 12:19:09 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB391AE19E for <6man@ietf.org>; Tue, 7 Jan 2014 12:19:09 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-0e-52cc61307894 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 3B.FE.23183.0316CC25; Tue, 7 Jan 2014 21:18:57 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0347.000; Tue, 7 Jan 2014 15:18:23 -0500 From: Samita Chakrabarti To: Mikael Abrahamsson , Mark ZZZ Smith Subject: RE: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 Thread-Topic: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 Thread-Index: AQHO5RSHI47a5UQsiE68Y1syr/NqV5otQZoAgC8iTSCAHNuAQIAArRYw Date: Tue, 7 Jan 2014 20:18:22 +0000 Message-ID: References: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> <1387528272.76757.YahooMailNeo@web161901.mail.bf1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZXLonVtcw8UyQwf3DLBYLOptYLVauuMtk cXrCVTaLl50b2Cwmt61gs5gx5R2jxculW9kc2D2m/N7I6nHw2EdGjyVLfjJ5PO1uZvH4O+kh k8eXy5/ZPL4fuMIUwB7FZZOSmpNZllqkb5fAlXH2+SPGgg3qFf23qxoYG+S7GDk5JARMJJ4d us8OYYtJXLi3nq2LkYtDSOAIo8SZM7uhnGWMEseaF7GBVLEJWEl09O4B6xARCJdYvfcjK0gR s8BtRolNa7uYQRLCAsESu75OhCoKkbh9YAobhO0m8b1lOpDNwcEioCKxZ4c+SJhXwFfi6aGd zBDLDjNJ3Fz0hwUkwSngLLHlzTJWEJsR6Lzvp9YwgdjMAuISt57MZ4I4W0BiyZ7zzBC2qMTL x/9YIWxlie9zHrFA1OtJ3JgKcQOzgLbEsoWvmSEWC0qcnPmEZQKj2CwkY2chaZmFpGUWkpYF jCyrGDlKi1PLctONDDYxAmPxmASb7g7GPS8tDzFKc7AoifN+eescJCSQnliSmp2aWpBaFF9U mpNafIiRiYNTqoFxxb0TKy4Zbw7ZJJWSn3E3qT0kgdM5KmptW3fex65LXbP28lYHLEiSvjAv 3ODx9QmbN3oE/OP5kDOr8GGC7FfORJMNd6O5+YscpA9NWzFt5x29tasPcARrGE8K4roU+Jax PEj5ZMXxmWte72qb+7Yvgb1btPztlF3bYzWUrm8PWcWlPCvp2NeXSizFGYmGWsxFxYkAlg1a mpMCAAA= Cc: 6man Chairs <6man-chairs@tools.ietf.org>, "6man@ietf.org" <6man@ietf.org>, "pthubert@cisco.com" , "Erik Nordmark \(nordmark@sonic.net\)" 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, 07 Jan 2014 20:19:12 -0000 Hi Mikael and Mark: Thanks for your comments and support on this draft. The following in-line comments discusses your suggestions - the part that i= s covered already and the part that can be improved during the progress of = the document.=20 -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 Sent: Tuesday, January 07, 2014 12:46 AM To: Mark ZZZ Smith Cc: Samita Chakrabarti; Ole Troan; 6man Chairs; 6man WG Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient= -nd-04 On Fri, 20 Dec 2013, Mark ZZZ Smith wrote: > Perhaps it might be better to treat the link as an NBMA subnet, and=20 > use > RFC2491 "IPv6 over Non-Broadcast Multiple Access (NBMA) networks" to=20 > eliminate all multicasts (including ND, MLD and application), except=20 > perhaps RAs with a flag=A0that indicate the link is operating in NBMA=20 > mode=A0(with RA timers larger than defaults - IIRC, the max router age=20 > value is 90 minutes, so unsolicited RAs can be around 30 minutes apart)? I have had similar thoughts. [SC>] ---------------------------------------------------------- It is in fact treating somewhat similar to IPv6 over NBMA to eliminate mult= icast and keeping a database to register all the hosts its serving and adve= rtising its capability of doing so in RA (E-bit). But these networks are NOT "non-broadcast" network -- for example behavior = of wireless network is shared, multi-accessed, sometimes battery powered et= c. Thus a registration is necessary to reliably handle the address resolut= ion and duplicate address detection. Erik can provide more details on the b= ackground on the registration need by having designed both RFC4861 and the = registration method mentioned in this document. In mixed mode, the document does allow RA timers with large time-intervals.= (section 12). If you prefer particular default interval [30min?], we can a= dd a parameter in the constants section (section 20). The current text at t= he end of section 12 says: "In mixed mode, the NEAR SHOULD have a configurable interval for periodic unsolicited router advertisements based on the media type." [SC>] ---------------------------------------------------------------------= ----------------------- I would like to have mode where no discovery is done at all anymore, and in= order to support legacy hosts, one way of doing that would be: Legacy hosts see RAs with M=3D1, and they are handed address using DHCPv6 I= A_NA if they ask for it. They will not see any on-link prefix, and will sen= d all traffic through the router. The router will install ND entry based on= lifetime of the DHCPv6 IA_NA. [SC>]---------------------------------------------------------------- The document , in mixed mode is silent about off-link Neighbor discovery f= or legacy routers and enhanced mode only supports off-link ND -- thus in en= hanced mode all packets are flowing through the NEAR.=20 Section 12 [ mixed mode section] "Both in mixed-mode and efficiency-aware mode, the NEAR sets E-bit flag in the RA and does not set 'L' on-link bit." The document does not restrict mixed mode legacy nodes to be off-link with= out understanding the full implications of the backward compatibility. [SC>] We have a section on DHCP interaction. Your proposal of using DHCPv6= IA_NA could apply there (section 17.3). Let's discuss the details off-li= ne. [SC>] ---------------------------------------------------- EAH will be able to do autoconfig by means of seeing an on-link /64 that is= in a RA option that differs in a way that legacy hosts won't use it (prefe= rrably also just unicasted to EAH by the router in response to RS).=20 EAH use ARO to register their address just as in the draft. If the router gets a packet to an address it doesn't have in the ND table, = it just drops the packet. All traffic on the LAN is routed through the rout= er, and optionally it can choose to send unicast redirects if it feels traf= fic is to hosts in the same L2 network. [SC>] ---------------------------------------------------------------------= ------- Exactly. Though the document does not encourage "redirect" messaging as it= is a general support for all kinds of links from wired to lossy and non-tr= ansitive radio links, optionally one can configure to have redirect messagi= ng if the deployment environment allows it. Here is an excerpt from the cur= rent text. Redirect Messages: A router SHOULD NOT send a Redirect message to a host since the link has non-transitive reachability. The host behavior is same as described in section 8.3 of RFC 4861[ND], i,e. a host MUST NOT send or accept redirect messages when in efficiency-aware mode. Same as in RFC 4861[ND] [SC>] Thanks so much. -Samita From lorenzo@google.com Wed Jan 8 02:49: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 3898A1AE235 for ; Wed, 8 Jan 2014 02:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, 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 YLsx68dv8sqJ for ; Wed, 8 Jan 2014 02:49:35 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id EF9AC1AE223 for ; Wed, 8 Jan 2014 02:49:34 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id ar20so1775753iec.2 for ; Wed, 08 Jan 2014 02:49:25 -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=5/iGc3NOwRJxI9/SjDc+Hd/3RsiW6lwJTlI+/NgFWwg=; b=hBFp7adOXLLz25dZ9Y3MoDjVrZUoiwu3YqtIHIie1FZ5d+GX/4/zfY1VjDFnxQX6u2 pT/ZdauIyEEgVpK6moJ6kq0NlnaT1rCscrJTIeGntq1ZsAtEui8yO2Evqco56Uf+j0L+ O9WAlTzzbwUE6mnaJqoXW0khNpn43mfXCScKyoBKy08H3ZXIGx1WOQ7cXm0ofXxE+2uy pjDgHn7AhgOB1o23wdg0C4lncGwPXFCVwSAE3u2nvK983jKJyk2pZAgYjEPn3tuZss+E FGZujwnxVFBpayYz6adnJFS1brd6ZNAi7/eDrwBNNSjWyHPanPLcHLnyv05+1yiKvLt6 Vi7Q== 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=5/iGc3NOwRJxI9/SjDc+Hd/3RsiW6lwJTlI+/NgFWwg=; b=DNkx2QbzNCjBf2XNdSzOB8iRNNvIrHx3OW7cuwVNHfHzoik9TrB4iqwX25GrgY0TCI oU6kYXQ0VLiMXlaXAl4iWvyknGO89Bq6Z0MddjnDgA1++kwNADZrMBkkbRu1BiQjy2XJ s6hqUoUPcOLKDOmFZ+WcYieqho0fVNb4gxkYkH7CgWH2DdbaCXbON+SMAcco8LY4QsIh JZNB3YD5HZgmtp+4RNxIoEftvNC03sjqzXo6NraDgs+DUFZs5ILYcBK7LF8Qz8tE2GDz jLG7s5k7FiOeo+MHz5UH+bzkw6j+FOVbPJTJD7n6FTKhWc+8zIlfYQV3I3bpGyHPF76D G64Q== X-Gm-Message-State: ALoCoQnFjanK0GW3smrMVvC0WciNTgm0Pxey1LwEf7MQkdgtATGyuUZFPwGgrPElfH4NQvAkiCRQ1WuCUGCNpo0C8Grkvyx15EOQPkV+q84HrHMIECM64IU9ePdC3+eKUCuNoeGsBkIX5lsGrmGxTyPNb/B/mpk3fQOLqSQc5SZ42rfoeG8casSM0B3f82zYOu5tcQGGFwI8 X-Received: by 10.50.61.137 with SMTP id p9mr31541980igr.45.1389178165304; Wed, 08 Jan 2014 02:49:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 8 Jan 2014 02:49:05 -0800 (PST) In-Reply-To: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> References: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> From: Lorenzo Colitti Date: Wed, 8 Jan 2014 19:49:05 +0900 Message-ID: Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 To: Ole Troan Content-Type: multipart/alternative; boundary=047d7bdca5dc12ce0a04ef733fc1 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 08 Jan 2014 10:49:37 -0000 --047d7bdca5dc12ce0a04ef733fc1 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 19, 2013 at 7:45 PM, Ole Troan wrote: > Please provide a view with reasons as to whether the WG should adopt this > or not. > > This message starts a one week 6MAN Working Group call on adopting: > > Title : Wired and Wireless IPv6 Neighbor Discovery > Optimizations > I do not support adoption of this draft. I do see the problem, but I think the proposed solution is the wrong trade-off. Let's consider examine the benefit. In most networks, the problems cited can be addressed using existing technology without requiring such a major overhaul of a core IPv6 protocol. For example, to take the problem areas mentioned in section 1.1: - It's true that periodic RA messages consume battery power, but this can be fixed by sending periodic RAs much less often and sending solicited RAs unicast, or by using DHCPv6 with long leases for address assignments. - It's true that NS/NA messages and RS do consume battery power, but unlike IPv4, ND cache entries don't time out, and thanks to the use of solicited-node multicast, NS messages are easy to filter either in the switches/APs or in the receiving devices' radio firmware. Also, the impact can be limited by using fewer nodes per link. - In many cases, it's possible to remove ND load entirely by setting the prefix to be off-link and having everything go through the first-hop router. In the case where the router is the same box as the AP, this has no scalability limitations at all. - It's true that on wifi, multicast/broadcast bandwidth is limited. However, this is not a problem in general-purpose networks. General-purpose networks typically run IPv4 as well, and IPv4 with ARP is way less efficient than standard ND. I think it's fair to say that in most networks, these measures will be sufficient to resolve most of the problems without having to alter the ND protocol. The cost of the proposed solution is significantly increasing the complexity and statefulness of the ND protocol, which is implemented, often in kernel space, in billions of general-purpose nodes. I think that's something that requires much more compelling reasons than the ones provided here. The concerns are not just implementation complexity, but also operational complexity, flexibility, and reliability. For example: part of the promise of IPv6 is that it allows networks to be simpler and more reliable. Putting more state in the network nullifies that promise. Don't get me wrong - I agree that in some networks these issues are critical, and something like this is needed. However, that's what 6lowpan is for. I think a much better tradeoff is for power-constrained devices to use their own ND protocol in their own low-power network (which connects to the rest of the network via a gateway), and to leave the general purpose ND protocol unchanged. --047d7bdca5dc12ce0a04ef733fc1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Nov 19, 2013 at 7:45 PM, Ole Troan <otroan@employees.org> wrote:
Please provide a view with reasons as to whether the WG sh= ould adopt this or not.

This message starts a one week 6MAN Working Group call on adopting:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Wire= d and Wireless IPv6 Neighbor Discovery Optimizations
<= br>
I do not support adoption of this draft. I do see the problem= , but I think the proposed solution is the wrong trade-off.

Let's consider examine the benefit. In most network= s, the problems cited can be addressed using existing technology without re= quiring such a major overhaul of a core IPv6 protocol. For example, to take= the problem areas mentioned in section 1.1:
  • It's true that periodic RA messages consume battery power,= but this can be fixed by sending periodic RAs much less often and sending = solicited RAs unicast, or by using DHCPv6 with long leases for address assi= gnments.
  • It's true that NS/NA messages and RS do consume battery power,= but unlike IPv4, ND cache entries don't time out, and thanks to the us= e of solicited-node multicast, NS messages are easy to filter either in the= switches/APs or in the receiving devices' radio firmware. Also, the im= pact can be limited by using fewer nodes per link.
  • In many cases, it's possible to remove ND load entirely by setting = the prefix to be off-link and having everything go through the first-hop ro= uter. In the case where the router is the same box as the AP, this has no s= calability limitations at all.
  • It's true that on wifi, multicast/broadcast bandwidth is limit= ed. However, this is not a problem in general-purpose networks. General-pur= pose networks typically run IPv4 as well, and IPv4 with ARP is way less eff= icient than standard ND.
I think it's fair to say that in most networks, these m= easures will be sufficient to resolve most of the problems without having t= o alter the ND protocol.


The cost o= f the proposed solution is significantly increasing the complexity and stat= efulness of the ND protocol, which is implemented, often in kernel space, i= n billions of general-purpose nodes. I think that's something that requ= ires much more compelling reasons than the ones provided here. The concerns= are not just implementation complexity, but also operational complexity, f= lexibility, and reliability. =C2=A0For example: part of the promise of IPv6= is that it allows networks to be simpler and more reliable. Putting more s= tate in the network nullifies that promise.


Don't get me wrong - I agree that in= some networks these issues are critical, and something like this is needed= . However, that's what 6lowpan is for.=C2=A0I think a much better trade= off is for power-constrained devices to use their own ND protocol in their = own low-power network (which connects to the rest of the network via a gate= way), and to leave the general purpose ND protocol unchanged.
--047d7bdca5dc12ce0a04ef733fc1-- From swmike@swm.pp.se Wed Jan 8 04:12: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 82C421AE357 for ; Wed, 8 Jan 2014 04:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.389 X-Spam-Level: X-Spam-Status: No, score=-4.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 XWWrTX4k3z6F for ; Wed, 8 Jan 2014 04:12:42 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 31C4B1AE2AA for ; Wed, 8 Jan 2014 04:12:42 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8F1C69C; Wed, 8 Jan 2014 13:12:32 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8AC579A; Wed, 8 Jan 2014 13:12:32 +0100 (CET) Date: Wed, 8 Jan 2014 13:12:32 +0100 (CET) From: Mikael Abrahamsson To: Lorenzo Colitti Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 In-Reply-To: Message-ID: References: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 08 Jan 2014 12:12:44 -0000 On Wed, 8 Jan 2014, Lorenzo Colitti wrote: > I think it's fair to say that in most networks, these measures will be > sufficient to resolve most of the problems without having to alter the > ND protocol. For me, another important issue to solve is the ND exhaustion when there is scanning going on. So for me, the value of this document is if there is a "non-discovery mode" of ND implemented. It might be better to do this in a different document, I don't know. So a mode where the clients use ARO to register their addresses, and legacy clients use DHCPv6 for IA_NA and the ND table is populated by these two mechanisms and packets destined for unknown IPv6 addresses are just dropped. This would be a big win, especially if it could be done with minimal changes to the clients. -- Mikael Abrahamsson email: swmike@swm.pp.se From alexandru.petrescu@gmail.com Wed Jan 8 04:17: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 B263F1AE36D for ; Wed, 8 Jan 2014 04:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, 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 cBTwvd4MDXPm for ; Wed, 8 Jan 2014 04:17:10 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 698DB1AE36C for ; Wed, 8 Jan 2014 04:17:10 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s08CH0Mp020400 for ; Wed, 8 Jan 2014 13:17:00 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CE69820324C for ; Wed, 8 Jan 2014 13:17:59 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C7237200BED for ; Wed, 8 Jan 2014 13:17:59 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s08CGsqs012388 for ; Wed, 8 Jan 2014 13:17:00 +0100 Message-ID: <52CD41B6.5020300@gmail.com> Date: Wed, 08 Jan 2014 13:16:54 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] References: <52C9D788.8060606@gmail.com> <52CBE0E6.5020107@globis.net> In-Reply-To: <52CBE0E6.5020107@globis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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, 08 Jan 2014 12:17:12 -0000 Le 07/01/2014 12:11, Ray Hunter a écrit : [...] > Where exactly is the requirement that IPv6 has to use /64 prefix > length really enshrined? Simply put, I agree with Brian that there is no one single specification place where this could be found enshrined. But a huge devil lies in details I dare uncover just a bit here. First, key places like the Addressing Architecture and SLAAC RFCs generally read as avoiding setting rigid limits on the prefix length or the Interface ID. For example the subnet prefix is said to be of length 'n', and the Interface ID of length '128-n'. But even there in RFC4291 there is a quirk saying: > For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format. (not sure what that 000 means). Then, an IP address being of fixed length, the prefix length could be inferred by looking at the length of the Interface ID, or other identifiers which look like it (e.g. an anycast IID). If that length is rigid, one may legitimately suppose strict limits on the prefix length as well. The IP-over-Ethernet RFC is precise in its limit of 64bit for the Interface ID. The success of its deployment made it so that others copy on it, together with that rigid limit. Today, not only Ethernet Interface IDs are precisely 64bit, but also WiFi, and, more surprisingly even 802.15.4 (surprisingly because even its short address on 16bit leads to an Interface ID on 64bits - 3rd par, sec 6 RFC 4944). Worse, other links which are not even documented as IP-over-foo RFCs do implement that 64bit limit although nobody requires them to. As for implementation enshrinment places there are many. One easy to spot is dmesg on modern linux upon reception of an RA containing a prefix whose length is 65, or 63 if one so wishes. Decimal. Alex From alexandru.petrescu@gmail.com Wed Jan 8 08:08: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 3BD251ADF8C for ; Wed, 8 Jan 2014 08:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, 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 4TarNMQ5riNA for ; Wed, 8 Jan 2014 08:08:53 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 319261AD68A for ; Wed, 8 Jan 2014 08:08:53 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s08G8dlp004803; Wed, 8 Jan 2014 17:08:39 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1F24820641A; Wed, 8 Jan 2014 17:09:39 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 11581206319; Wed, 8 Jan 2014 17:09:39 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s08G8ZZ9017745; Wed, 8 Jan 2014 17:08:39 +0100 Message-ID: <52CD7803.5050008@gmail.com> Date: Wed, 08 Jan 2014 17:08:35 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ray Hunter , Brian E Carpenter Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] References: <52C9D788.8060606@gmail.com> <52CBE0E6.5020107@globis.net> In-Reply-To: <52CBE0E6.5020107@globis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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, 08 Jan 2014 16:08:55 -0000 Le 07/01/2014 12:11, Ray Hunter a écrit : [...] > It should be perfectly feasible to allocate a /64 to a router interface > in an IPAM tool, but then configure the equivalent of n prefixes each > containing 1 or 2 address with prefix length /128 or /127 (depending on > the implementation) Would these hosts use some form of address auto-configuration? But yes, I agree with the point that this should be possible. [...] > Anyway, in the majority of modern day wired deployments, the delta cost > of L3 over L2 is minimal, as the most dominant form of wired LAN > (Ethernet) are commonly switched in silicon, and multicast has to be > emulated. Wired Ethernet has in effect become a point to point protocol. > So deploying a dedicated L3 connection per end host is both technically > and financially feasible, and may have significant operational benefits > in certain scenarios. Allocating a /64 for each such port on a L3 switch > is sub optimal IMHO. And by the same privacy argument, allocating n > hosts sparsely over a single /64 of address space spread over multiple > L3 interfaces would have the same net effect for off-net attackers as n > hosts sharing a flat L2 LAN using a single /64, with the added advantage > that even locally the individual end nodes would not be able to > passively observe each other's traffic or addresses (advantageous in > shared hosting environments). I agree that with large switches and VLANs often the links look very much as point to point links. > An attacker that happens to discover the address of node A would not > find this information helpful in attempts to locate node B, any more > than if it were a flat /64. > > So to me it's a non-relevant argument one way or the other. > > Section 2.2 > > It may not be a widely held belief, but I remain concerned about the > potential for resource exhaustion for any number of processes due to the > "massive over sizing" of prefixes to /64: any number of untested > processes that track state based on /128 IPv6 address could be attacked. Right. Alex > The flip side of expanding privacy through address obfuscation at IID > level is that the source space available for attacks also increases. ND > cache exhaustion is probably just the first issue we've discovered of > many that exist. This may have knock on operational consequences, which > in the IPv4 world have relied on the scarcity of IPv4 address space to > be able to operate correctly under stress scenarios. We're going to > discover who has been swimming naked when the tide goes out. Call that > FUD, or operational expediency, whichever you like. BCP38 has saved me > on a number of occasions when all else has failed. > > From alexandru.petrescu@gmail.com Wed Jan 8 08:19: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 03A041ADFA7 for ; Wed, 8 Jan 2014 08:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, 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 uJIkzro_rEy8 for ; Wed, 8 Jan 2014 08:19:45 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id D26431ADFB7 for ; Wed, 8 Jan 2014 08:19:44 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s08GJZhY008580 for ; Wed, 8 Jan 2014 17:19:35 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CBF15206439 for ; Wed, 8 Jan 2014 17:20:34 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C4A19206319 for ; Wed, 8 Jan 2014 17:20:34 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s08GJVSv025717 for ; Wed, 8 Jan 2014 17:19:34 +0100 Message-ID: <52CD7A93.4030908@gmail.com> Date: Wed, 08 Jan 2014 17:19:31 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] References: <52C9D788.8060606@gmail.com> <1389041504.19037.YahooMailNeo@web161905.mail.bf1.yahoo.com> In-Reply-To: <1389041504.19037.YahooMailNeo@web161905.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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, 08 Jan 2014 16:19:47 -0000 Le 06/01/2014 21:51, Mark ZZZ Smith a écrit : > Hi, > > I've had a quick read through, I think this document would be quite > useful. > > One thing I think would be good to capture is a bit of the > history/rational behind the choice of 64 IID. > > I became aware of that history via Christian Huitema's "IPv6: The > New Internet Protocol (2nd Edition)" book, I think it would be good > if that history was a bit more widely available to explain and > justify the choice. Hi, I dont have the book handy, but I would be interested to learn about how this 64bit length came to life. I remember some discussions of an 'h' factor. I suppose IEEE's EUI-64 design history is related, maybe because triggered by same fear of address space depletion (48bit identifiers); knowing that one may see how would an EUI-128 influence in any way IPv6 addressing. Alex > > Regards, Mark. > > > ----- Original Message ----- >> From: Brian E Carpenter To: 6man >> Cc: Sent: Monday, 6 January 2014 9:07 AM Subject: >> [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] >> >> Hi, >> >> A group of us put this together following a discussion some weeks >> ago on the v6ops list about the 64-bit boundary in IPv6 addresses. >> Discussion belongs in 6man, please. >> >> This draft is incomplete but we'd welcome input. Let me underline >> an important comment in the introduction: >> >> _The purpose of this document is to analyse the issues around this >> question. We make no proposal for change, but we do analyse the >> possible effects of a change._ >> >> >> Brian + co-authors >> >> -------- Original Message -------- Subject: I-D Action: >> draft-carpenter-6man-why64-00.txt Date: Sun, 05 Jan 2014 13:59:17 >> -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-00.txt Pages : 14 Date : >> 2014-01-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-00 >> >> >> >> >> >> >> >> >> >> -------------------------------------------------------------------- >> >> >> >> >> 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 brian.e.carpenter@gmail.com Wed Jan 8 11:17: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 0EE391AE0F9 for ; Wed, 8 Jan 2014 11:17:01 -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 UpxD4vN7o4SR for ; Wed, 8 Jan 2014 11:16:58 -0800 (PST) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id B319E1AE09C for ; Wed, 8 Jan 2014 11:16:58 -0800 (PST) Received: by mail-pd0-f179.google.com with SMTP id r10so2130538pdi.24 for ; Wed, 08 Jan 2014 11:16:49 -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=SatKsc0oTxVE4X+OP3lgsO0cXAnNxlohF72Q6s8iuzw=; b=Q2Ln0X8DzOP+T27HCoZXk3Flht7OaxjtYZ66koYIvST11HpWaOZH0UVQf26bWIi0pc miDgSp/+dUtWlI/JGihpfb2FuWzlnVrMKFf/Wb9HLq6hh5uFmGo5shOM4V27PV5WT0p7 8kSvp91quy7AY6LztS3XILau7MT+W+RJcKOO4vnQRXfWzoPUbneNWaWqZD0H9GuyDy0+ FybmsW8R8thmhw4eAqiTvIM+XFNTRYfIu5xri31oN5EvYpX5G6gJeukttJymdv4+8oNU hzyVOQBCvtqCr39NOpLIf7dKkGWKg39UzlSgNrSRnnXBq9ot4xr3MyHxmSDdNBOVGzOe OiIw== X-Received: by 10.66.227.104 with SMTP id rz8mr14993420pac.74.1389208609597; Wed, 08 Jan 2014 11:16:49 -0800 (PST) Received: from [192.168.178.21] (81.196.69.111.dynamic.snap.net.nz. [111.69.196.81]) by mx.google.com with ESMTPSA id qz9sm4390778pbc.3.2014.01.08.11.16.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Jan 2014 11:16:48 -0800 (PST) Message-ID: <52CDA427.80906@gmail.com> Date: Thu, 09 Jan 2014 08:16:55 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] References: <52C9D788.8060606@gmail.com> <1389041504.19037.YahooMailNeo@web161905.mail.bf1.yahoo.com> <52CD7A93.4030908@gmail.com> In-Reply-To: <52CD7A93.4030908@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, 08 Jan 2014 19:17:01 -0000 EUI-64 came first; it's used by Firewire and there was some expectation that Firewire would become very important, or in general that EUI-64 would come to replace EUI-48. But maybe someone who has Christian's book could send a paraphrase of his explanation. Regards Brian On 09/01/2014 05:19, Alexandru Petrescu wrote: > Le 06/01/2014 21:51, Mark ZZZ Smith a =C3=A9crit : >> Hi, >> >> I've had a quick read through, I think this document would be quite >> useful. >> >> One thing I think would be good to capture is a bit of the >> history/rational behind the choice of 64 IID. >> >> I became aware of that history via Christian Huitema's "IPv6: The >> New Internet Protocol (2nd Edition)" book, I think it would be good >> if that history was a bit more widely available to explain and >> justify the choice. >=20 > Hi, >=20 > I dont have the book handy, but I would be interested to learn about ho= w > this 64bit length came to life. I remember some discussions of an 'h' > factor. >=20 > I suppose IEEE's EUI-64 design history is related, maybe because > triggered by same fear of address space depletion (48bit identifiers); > knowing that one may see how would an EUI-128 influence in any way IPv6= > addressing. >=20 > Alex >=20 >> >> Regards, Mark. >> >> >> ----- Original Message ----- >>> From: Brian E Carpenter To: 6man >>> Cc: Sent: Monday, 6 January 2014 9:07 AM Subject: >>> [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] >>> >>> Hi, >>> >>> A group of us put this together following a discussion some weeks >>> ago on the v6ops list about the 64-bit boundary in IPv6 addresses. >>> Discussion belongs in 6man, please. >>> >>> This draft is incomplete but we'd welcome input. Let me underline >>> an important comment in the introduction: >>> >>> _The purpose of this document is to analyse the issues around this >>> question. We make no proposal for change, but we do analyse the >>> possible effects of a change._ >>> >>> >>> Brian + co-authors >>> >>> -------- Original Message -------- Subject: I-D Action: >>> draft-carpenter-6man-why64-00.txt Date: Sun, 05 Jan 2014 13:59:17 >>> -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-00.txt Pages : 14 Date : >>> 2014-01-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-00 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -------------------------------------------------------------------- >>> >>> >>> >>> >>> > IETF IPv6 working group mailing list >>> ipv6@ietf.org Administrative Requests: >>> https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> >>> >>> >>> >>> > -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From wwwrun@rfc-editor.org Wed Jan 8 13:47: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 983901A1F7D; Wed, 8 Jan 2014 13:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 YNTv7XKvmqk8; Wed, 8 Jan 2014 13:47:07 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 98BD51A1F6F; Wed, 8 Jan 2014 13:47:07 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 2D4267FC393; Wed, 8 Jan 2014 13:46:58 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 7048 on Neighbor Unreachability Detection Is Too Impatient From: rfc-editor@rfc-editor.org Message-Id: <20140108214658.2D4267FC393@rfc-editor.org> Date: Wed, 8 Jan 2014 13:46:58 -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: Wed, 08 Jan 2014 21:47:09 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7048 Title: Neighbor Unreachability Detection Is Too Impatient Author: E. Nordmark, I. Gashinsky Status: Standards Track Stream: IETF Date: January 2014 Mailbox: nordmark@acm.org, igor@yahoo-inc.com Pages: 8 Characters: 17946 Updates: RFC 4861 I-D Tag: draft-ietf-6man-impatient-nud-07.txt URL: http://www.rfc-editor.org/rfc/rfc7048.txt IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. That function is very useful when a host has an alternative neighbor -- for instance, when there are multiple default routers -- since it allows the host to switch to the alternative neighbor in a short time. By default, this time is 3 seconds after the node starts probing. However, if there are no alternative neighbors, this timeout behavior is far too impatient. This document specifies relaxed rules for Neighbor Discovery retransmissions that allow an implementation to choose different timeout behavior based on whether or not there are alternative neighbors. This document updates RFC 4861. 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 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 wwwrun@rfc-editor.org Wed Jan 8 13:47: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 C5FFC1AC49D; Wed, 8 Jan 2014 13:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 y8FbCWMtWotE; Wed, 8 Jan 2014 13:47:13 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id BCD7C1AC3FA; Wed, 8 Jan 2014 13:47:13 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 725547FC3A3; Wed, 8 Jan 2014 13:47:04 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 7078 on Distributing Address Selection Policy Using DHCPv6 From: rfc-editor@rfc-editor.org Message-Id: <20140108214704.725547FC3A3@rfc-editor.org> Date: Wed, 8 Jan 2014 13:47:04 -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: Wed, 08 Jan 2014 21:47:16 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7078 Title: Distributing Address Selection Policy Using DHCPv6 Author: A. Matsumoto, T. Fujisaki, T. Chown Status: Standards Track Stream: IETF Date: January 2014 Mailbox: arifumi@nttv6.net, fujisaki@nttv6.net, tjc@ecs.soton.ac.uk Pages: 12 Characters: 25094 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-6man-addr-select-opt-13.txt URL: http://www.rfc-editor.org/rfc/rfc7078.txt RFC 6724 defines default address selection mechanisms for IPv6 that allow nodes to select an appropriate address when faced with multiple source and/or destination addresses to choose between. RFC 6724 allows for the future definition of methods to administratively configure the address selection policy information. This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy overriding the default address selection parameters and policy table, and thus allowing the administrator to control the address selection behavior of nodes in their site. 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 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 lorenzo@google.com Wed Jan 8 17:53: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 012031ADFB0 for ; Wed, 8 Jan 2014 17:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, 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 0UcPATYMaoxl for ; Wed, 8 Jan 2014 17:53:32 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 84B151ADF8E for ; Wed, 8 Jan 2014 17:53:32 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id ut6so6293548igb.5 for ; Wed, 08 Jan 2014 17:53:23 -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=mbo3yGKtotSTSnmjMqCtKjLZiWOvrdb+R+Ce8BQiVMM=; b=P4EYBnzetv7EhgOkhr/Hyed0Iw6JfUSzYvAuzCqnYjSLVEwnuJJaJGT/YFxFU91xof ju98UlD1E4O/igc7Z36Z4s0L6sTkSnMMrYATygXuavsgLur2RC+g7by6jv4lpVGu4+kW gJP8ILq1VYpnSmppGhshe+TL5m10118460m+cp6jnLOqekcbfk81epbK3OhDlc5GvDov 5RWAmt3rKBNvntZsa2HTPs/N6kScE7ia4AQljuRSDlUZuV++XdJjFhidsxJ5acqcHnR4 ATtmI1tXJdgzyXyhYkuNZpRlNdACKN6NaRhHe2dQo35WYjcY00SH8ZxKqBjMKJKSZd6K G5mw== 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=mbo3yGKtotSTSnmjMqCtKjLZiWOvrdb+R+Ce8BQiVMM=; b=AsVnQdlfwU7OX+VMC6hxUkjQH0s0zD5f6ioSAErj7C9prHw5gWkoN/aqu8jRvg9Y/7 +2UXwIsTmmdu5FGWUu7BEXLNMIILgjWlETHZusv1RLnUvhu3HOov1JvuHxjxZLFTJxHr Gd63SX0M9P5vdveyHSybGYswY5z7GigT6APSwtDrg+VhAxk1oruYK8TVBjEH9WQUMi72 xA8RkFjyzjAeQFXur+ONkOQ+NB3e2yNqd+l6W+PJwZz6tnvKY89kgiaVCug50dHaby4L u81pvcQzA2faiKSg14BhbSX/me/9k25FopXdx0PpukW/m3vcHrGyi/D2RD4YvWrJNDug WIuQ== X-Gm-Message-State: ALoCoQnpWygxTV+szsVoVzQJtKpFljiLBKUXA14OzOlEZ0/1axDSL/yCmkVDp3NYotxysKxGOweR+ZD9t8jQk11mHGs9SsD3QpmW7OA/MEPpiQxqaYf7usnuEQe1lMDAGypmOwdDFcdUMurqJhgHRW/2Jb+oZj8lnXUs65saU7N3PqdpIgLql0q1lQKyPr6GcdONkwy/BuLI X-Received: by 10.43.138.8 with SMTP id iq8mr245336icc.37.1389232402965; Wed, 08 Jan 2014 17:53:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 8 Jan 2014 17:53:02 -0800 (PST) In-Reply-To: References: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> From: Lorenzo Colitti Date: Thu, 9 Jan 2014 10:53:02 +0900 Message-ID: Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=001a11c20364e3d87604ef7fdfb0 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 09 Jan 2014 01:53:34 -0000 --001a11c20364e3d87604ef7fdfb0 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 8, 2014 at 9:12 PM, Mikael Abrahamsson wrote: > For me, another important issue to solve is the ND exhaustion when there > is scanning going on. So for me, the value of this document is if there is > a "non-discovery mode" of ND implemented. It might be better to do this in > a different document, I don't know. > > So a mode where the clients use ARO to register their addresses, and > legacy clients use DHCPv6 for IA_NA and the ND table is populated by these > two mechanisms and packets destined for unknown IPv6 addresses are just > dropped. > > This would be a big win, especially if it could be done with minimal > changes to the clients. You don't need to modify ND to do that, though. You can defend against that sort of attack by having the ND implementation: 1. Prioritize preserving ND cache entries over making new address resolution attempts. 2. Glean ND cache entries from DAD packets (and if need be, NS/NA packets), and prioritize those gleaned entries over new address resolution attempts. Some of these measures are documented in RFC 6583. --001a11c20364e3d87604ef7fdfb0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 8, 2014 at 9:12 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
For= me, another important issue to solve is the ND exhaustion when there is sc= anning going on. So for me, the value of this document is if there is a &qu= ot;non-discovery mode" of ND implemented. It might be better to do thi= s in a different document, I don't know.

So a mode where the clients use ARO to register their addresses, and legacy= clients use DHCPv6 for IA_NA and the ND table is populated by these two me= chanisms and packets destined for unknown IPv6 addresses are just dropped.<= br>
This would be a big win, especially if it could be done with minimal change= s to the clients.

You don't need to mod= ify ND to do that, though. You can defend against that sort of attack by ha= ving the ND implementation:

1. Prioritize preserving ND cache entries over making n= ew address resolution attempts.
2. Glean ND cache entries from DA= D packets (and if need be, NS/NA packets), and prioritize those gleaned ent= ries over new address resolution attempts.

Some of these measures are documented in RFC 6583.
--001a11c20364e3d87604ef7fdfb0-- From lorenzo@google.com Wed Jan 8 18:28: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 B855F1ADFFB for ; Wed, 8 Jan 2014 18:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, 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 Hs9Okmiz6Jba for ; Wed, 8 Jan 2014 18:28:30 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1B41ADFFA for ; Wed, 8 Jan 2014 18:28:30 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id tp5so2985265ieb.11 for ; Wed, 08 Jan 2014 18:28:21 -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=tSDLqNGggz0FpdKmYwENS0kZ/UbMIkFGo/CNnujNjdo=; b=IXETTkAt3El16GoYKXZhIHSaLdrfz0wUKba/Xx3n3UX9lx52Ooyn9boMMQ4FEngfto v7X0jPeDqDDXehflYTam68sV55nu2japZlOz6TbCt+iUvRP9RXyr3wy4oU1H2dsq6sNN 0uorhTW7jxoacQxUxxic9tc9xep//877HdotKW8q6PcyTWAiIrFMHQ/bSMf9PnqGBkyY JZb2RXlJJ7XCztrjFkd2bCbk9RjxL0YBhM9nxNwEoIgSrDyTHl8KNyyjqPVlfT4stUAb 6WD2GwLfSvu89PdxeXKnhB5RZgQdA98zEc1+pzXL0WFEz/D9WneEeW6RV1NujjzCbyrj NclA== 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=tSDLqNGggz0FpdKmYwENS0kZ/UbMIkFGo/CNnujNjdo=; b=AA0CVYNTO2g0iuLsYo33CegzioXdpgMmEzIZpVHGXRBomIJuXBs3IfNYB7HtKGH66i ZuIu9Qn6/ByjVG6mmmFAmWdj+jcP9a0KtUMT1HbrABtQqM2UrMXeU3Un0Jm4Pa1ij5tB IkK7JZc4s82cxF1fVlkedJqUYLN8wSEXPKGLxw6ptcVhPU0l9uU78rwEUtMNzGT4HDn8 giFbqWmJae0YZPsKsOd8StBE2sDroDF+mqTzQPqT/jZ7REqhx6ZGfQLFthOhUf9fmpYI wN0uo7vTwoQt2nksCCsY+3t/qT4lZHE4rET4ZZusXOFIgq1lG/9CXmyKb9XgDJxro5AE PThQ== X-Gm-Message-State: ALoCoQmchQwkK3jwk/vsXtPfGGAMDYAKzZrh6LVJjPl7FQBd+xHX2CC9PreWnIYAP4Krcpas5GKL6nOB6T2ik9E0aESMHFaFNGcIq/i8coRUpMqpJX3qt6H+UOXos+P4MtAiTc0HJMs8H5FFhnYZksTfev4kCWOFjIEUE4fx9xn2VWuRposNawbZ2hB/5FvwsSjAgUqVMrl5 X-Received: by 10.50.61.101 with SMTP id o5mr836411igr.31.1389234500001; Wed, 08 Jan 2014 18:28:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 8 Jan 2014 18:27:58 -0800 (PST) In-Reply-To: <52CBE0E6.5020107@globis.net> References: <52C9D788.8060606@gmail.com> <52CBE0E6.5020107@globis.net> From: Lorenzo Colitti Date: Thu, 9 Jan 2014 11:27:58 +0900 Message-ID: Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] To: Ray Hunter Content-Type: multipart/alternative; boundary=001a11360350e1fd5f04ef805c79 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: Thu, 09 Jan 2014 02:28:32 -0000 --001a11360350e1fd5f04ef805c79 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 7, 2014 at 8:11 PM, Ray Hunter wrote: > It may not be a widely held belief, but I remain concerned about the > potential for resource exhaustion for any number of processes due to the > "massive over sizing" of prefixes to /64: any number of untested processes > that track state based on /128 IPv6 address could be attacked. The flip > side of expanding privacy through address obfuscation at IID level is that > the source space available for attacks also increases. ND cache exhaustion > is probably just the first issue we've discovered of many that exist. This > may have knock on operational consequences, which in the IPv4 world have > relied on the scarcity of IPv4 address space to be able to operate > correctly under stress scenarios. We're going to discover who has been > swimming naked when the tide goes out. Call that FUD, or operational > expediency, whichever you like. BCP38 has saved me on a number of occasions > when all else has failed. > It's true that some implementations may have made incorrect assumptions about IPv6 attacks based on their IPv4 knowledge. But on the other hand, a /64 provides plentiful space, freedom from renumbering, and operational simplicity because "you will always have enough subnet space" and "you can pick your own IID because a /64 provides enough space for everyone". I don't think it's a good trade-off to give up those advantages just because of some implementations may temporarily have made insecure choices. By the same token, we didn't design IPv4 to be partitioned into security zones, even though I'm sure that when IPv4 rolled around, people were shocked - and I'm sure some got burnt - by the fact that enabling IPv4 on a machine suddenly meant that the machine was suddenly accessible from anywhere in the world. I think it's much better to start with a flexible, full-featured, simple architecture and them secure it. It's not that securing it is hard to do: in first instance, make the abuse systems just track /64s instead of tracking /128s, and problem solved. Of course, you still have the problem that there are too many /64s to keep track of, but there's no way around that except to stick with IPv4, or make a new protocol that has more address space than IPv4 but less address space than IPv6... but why would you want that? I know that smaller subnets are consistent with IPv4. But "different from IPv4" doesn't mean "worse than IPv4". In many cases, it means "better than IPv4". --001a11360350e1fd5f04ef805c79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 7, 2014 at 8:11 PM, Ray Hunter <v6ops@globis.net> wro= te:
It ma= y not be a widely held belief, but I remain concerned about the potential f= or resource exhaustion for any number of processes due to the "massive= over sizing" of prefixes to /64: any number of untested processes tha= t track state based on /128 IPv6 address could be attacked. The flip side o= f expanding privacy through address obfuscation at IID level is that the so= urce space available for attacks also increases. ND cache exhaustion is pro= bably just the first issue we've discovered of many that exist. This ma= y have knock on operational consequences, which in the IPv4 world have reli= ed on the scarcity of IPv4 address space to be able to operate correctly un= der stress scenarios. We're going to discover who has been swimming nak= ed when the tide goes out. Call that FUD, or operational expediency, whiche= ver you like. BCP38 has saved me on a number of occasions when all else has= failed.

It's true that some implementati= ons may have made incorrect assumptions about IPv6 attacks based on their I= Pv4 knowledge. But on the other hand, a /64 provides plentiful space, freed= om from renumbering, and operational simplicity because "you will alwa= ys have enough subnet space" and "you can pick your own IID becau= se a /64 provides enough space for everyone".

I don't think it's a good trade-off to give up = those advantages just because of some implementations may temporarily have = made insecure choices. By the same token, we didn't design IPv4 to be p= artitioned into security zones, even though I'm sure that when IPv4 rol= led around, people were shocked - and I'm sure some got burnt - by the = fact that enabling IPv4 on a machine suddenly meant that the machine was su= ddenly accessible from anywhere in the world. I think it's much better = to start with a flexible, full-featured, simple architecture and them secur= e it.

It's not that securing it is hard to do:= in first instance, make the abuse systems just track /64s instead of track= ing /128s, and problem solved. Of course, you still have the problem that t= here are too many /64s to keep track of, but there's no way around that= except to stick with IPv4, or make a new protocol that has more address sp= ace than IPv4 but less address space than IPv6... but why would you want th= at?

I know that smaller subnets are consistent w= ith IPv4. But "different from IPv4" doesn't mean "worse = than IPv4". In many cases, it means "better than IPv4".
--001a11360350e1fd5f04ef805c79-- From ggm@algebras.org Wed Jan 8 18: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 8FE821AE010 for ; Wed, 8 Jan 2014 18:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 CNtMlqZJWJ66 for ; Wed, 8 Jan 2014 18:38:19 -0800 (PST) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by ietfa.amsl.com (Postfix) with ESMTP id 613F71ADFBB for ; Wed, 8 Jan 2014 18:38:19 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id kp14so2664915pab.19 for ; Wed, 08 Jan 2014 18:38:10 -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:content-type; bh=ZNWEBDoB9iMyPTAtwziOQmbgO4YLnBWwVBVKEaUVW7A=; b=epCz9pJM+H4PK20xrTZjc0SUNd9rvz/IjNNm/3UjpRZ3411NMnlLKay4dmsoLYQVP/ Y+cGZo0cOcsIOwp8l1s6N179iVl8tF/MoKreO77psoxP6g1zl571hvu1W+9GpftDfdg5 /yf+v06RLqatyUOPKTaeqN+asRkLkyyM/WvEx46cgeFrapC2M8FUiKggCrPKCSA09vY3 3XKT3bREpNtIgWXMHiuuwI3Njr3ShqwHMSeEtr2BTwjQJJvVUu7ltNt6lnhAkzGX7+nw ABCjAMj8Q8fV5514MVKmxeChl8LgjI9YWKaLdeJl7/7xAMUNx2o5G7sI+xkvIlk7U6K/ Pgew== X-Gm-Message-State: ALoCoQmLmr96NpEvLXOMtgTYU+5nDywiCZBYQXSe6JgkC3xiCyTiqMf+VZEr2JJFhAhbR9Z7lllb MIME-Version: 1.0 X-Received: by 10.68.236.35 with SMTP id ur3mr563897pbc.137.1389235090103; Wed, 08 Jan 2014 18:38:10 -0800 (PST) Received: by 10.70.87.144 with HTTP; Wed, 8 Jan 2014 18:38:10 -0800 (PST) X-Originating-IP: [2001:dc0:a000:4:a5fe:d3bc:470f:ea5] In-Reply-To: References: <52C9D788.8060606@gmail.com> <52CBE0E6.5020107@globis.net> Date: Thu, 9 Jan 2014 12:38:10 +1000 Message-ID: Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] From: George Michaelson To: 6man Content-Type: multipart/alternative; boundary=047d7b33d6280e59c704ef808087 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, 09 Jan 2014 02:38:21 -0000 --047d7b33d6280e59c704ef808087 Content-Type: text/plain; charset=ISO-8859-1 AVLs and other data structures cope fine with IPv6. Its true you have to have a heap and pointers, rather than a statically sized array, but I think if you want to change address architecture because you think arrays are the only construct to process integers, you really have bigger problems. They're bitstrings. They sort well in patricia trie On Thu, Jan 9, 2014 at 12:27 PM, Lorenzo Colitti wrote: > On Tue, Jan 7, 2014 at 8:11 PM, Ray Hunter wrote: > >> It may not be a widely held belief, but I remain concerned about the >> potential for resource exhaustion for any number of processes due to the >> "massive over sizing" of prefixes to /64: any number of untested processes >> that track state based on /128 IPv6 address could be attacked. The flip >> side of expanding privacy through address obfuscation at IID level is that >> the source space available for attacks also increases. ND cache exhaustion >> is probably just the first issue we've discovered of many that exist. This >> may have knock on operational consequences, which in the IPv4 world have >> relied on the scarcity of IPv4 address space to be able to operate >> correctly under stress scenarios. We're going to discover who has been >> swimming naked when the tide goes out. Call that FUD, or operational >> expediency, whichever you like. BCP38 has saved me on a number of occasions >> when all else has failed. >> > > It's true that some implementations may have made incorrect assumptions > about IPv6 attacks based on their IPv4 knowledge. But on the other hand, a > /64 provides plentiful space, freedom from renumbering, and operational > simplicity because "you will always have enough subnet space" and "you can > pick your own IID because a /64 provides enough space for everyone". > > I don't think it's a good trade-off to give up those advantages just > because of some implementations may temporarily have made insecure choices. > By the same token, we didn't design IPv4 to be partitioned into security > zones, even though I'm sure that when IPv4 rolled around, people were > shocked - and I'm sure some got burnt - by the fact that enabling IPv4 on a > machine suddenly meant that the machine was suddenly accessible from > anywhere in the world. I think it's much better to start with a flexible, > full-featured, simple architecture and them secure it. > > It's not that securing it is hard to do: in first instance, make the abuse > systems just track /64s instead of tracking /128s, and problem solved. Of > course, you still have the problem that there are too many /64s to keep > track of, but there's no way around that except to stick with IPv4, or make > a new protocol that has more address space than IPv4 but less address space > than IPv6... but why would you want that? > > I know that smaller subnets are consistent with IPv4. But "different from > IPv4" doesn't mean "worse than IPv4". In many cases, it means "better than > IPv4". > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > --047d7b33d6280e59c704ef808087 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
AVLs and other data structures cope fine with IPv6. Its tr= ue you have to have a heap and pointers, rather than a statically sized arr= ay, but I think if you want to change address architecture because you thin= k arrays are the only construct to process integers, you really have bigger= problems.

They're bitstrings. They sort well in patricia trie


On Thu= , Jan 9, 2014 at 12:27 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
=
On Tue, Jan 7, 2014 at 8:11 PM, Ray Hunter <v6op= s@globis.net> wrote:
It may not be a widely held b= elief, but I remain concerned about the potential for resource exhaustion f= or any number of processes due to the "massive over sizing" of pr= efixes to /64: any number of untested processes that track state based on /= 128 IPv6 address could be attacked. The flip side of expanding privacy thro= ugh address obfuscation at IID level is that the source space available for= attacks also increases. ND cache exhaustion is probably just the first iss= ue we've discovered of many that exist. This may have knock on operatio= nal consequences, which in the IPv4 world have relied on the scarcity of IP= v4 address space to be able to operate correctly under stress scenarios. We= 're going to discover who has been swimming naked when the tide goes ou= t. Call that FUD, or operational expediency, whichever you like. BCP38 has = saved me on a number of occasions when all else has failed.

It's true that some implementati= ons may have made incorrect assumptions about IPv6 attacks based on their I= Pv4 knowledge. But on the other hand, a /64 provides plentiful space, freed= om from renumbering, and operational simplicity because "you will alwa= ys have enough subnet space" and "you can pick your own IID becau= se a /64 provides enough space for everyone".

I don't think it's a good trade-off to give up = those advantages just because of some implementations may temporarily have = made insecure choices. By the same token, we didn't design IPv4 to be p= artitioned into security zones, even though I'm sure that when IPv4 rol= led around, people were shocked - and I'm sure some got burnt - by the = fact that enabling IPv4 on a machine suddenly meant that the machine was su= ddenly accessible from anywhere in the world. I think it's much better = to start with a flexible, full-featured, simple architecture and them secur= e it.

It's not that securing it is hard to do:= in first instance, make the abuse systems just track /64s instead of track= ing /128s, and problem solved. Of course, you still have the problem that t= here are too many /64s to keep track of, but there's no way around that= except to stick with IPv4, or make a new protocol that has more address sp= ace than IPv4 but less address space than IPv6... but why would you want th= at?

I know that smaller subnets are consistent w= ith IPv4. But "different from IPv4" doesn't mean "worse = than IPv4". In many cases, it means "better than IPv4".

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


--047d7b33d6280e59c704ef808087-- From lorenzo@google.com Wed Jan 8 18:43: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 792A21AE021 for ; Wed, 8 Jan 2014 18:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, 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 WGaZV7MeDKUN for ; Wed, 8 Jan 2014 18:43:54 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 358961AE010 for ; Wed, 8 Jan 2014 18:43:54 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id lx4so2876199iec.23 for ; Wed, 08 Jan 2014 18:43:44 -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=XHsGJF5ugfeaiNJj1ttpCL8OiDmFyhoa7K42CQIdhy4=; b=eSB0b4rTIr/VZRInGZy8DPg5eFTrIoIjzAAVvMTXiHpqtkAJlQq71vrBtY5au4gNrV qN/vr7JkTiO04xeyI+AoOZZgEc62ec4B2HqFXmdRlIHk+CizrI+tzTlywhisWzOh6KCL GK06d4mJ3GMpcuJkqrPn7sQhLJvug2sDMhdEezubdkan/OViteUERA+JPble8dodnWnJ Sv156iFUS0q+zj82JYWerxd3IEmcC8VW1W2UIqfL4Z3ew1dkowkxOx5kggL+86Lc5joh e63ExTNjrqPhLptdGds7EL9rnMlD6Mt6gS8JbPQckD6ODVhO30mIFvXWx3we9BtEDsMD f89A== 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=XHsGJF5ugfeaiNJj1ttpCL8OiDmFyhoa7K42CQIdhy4=; b=Mt4hOTk6m7cZFUFpyz91FRuhQmII1bsWd4w/e8IMvD1Bm8RdKbfoo/MuwhjDbVc5L9 wmclV65L/lE0Dgl8O5xRSFeMeHEkNcQGtGxIQOyc2qp2VttUR+7vUPmH+3Yf2b2P8lI3 ViEqBcMMlR5Ia2ay6IeA/TXcijM0NvoLuvsrCge6wcJCVLoQG0r6dEqxsnBzDv3sNLBs GJu0df4ENkwmMEm5HUop/wRQZ8ZOAjLCh5Pa9ee5ucmiqIOOSO4J7zL2n+81g0zHlF3j QRvqe5VS9OioyBrLBVZK4o2/Qd9fieYYcefB2mkMrnBVV0p/xPfReemLyuWk1c1N7PF/ 3UHQ== X-Gm-Message-State: ALoCoQkOgxsoqipBhrzptutP2thAcQ4ilD4oZQ9NU/kG0MycNUuU13t4aM8QxDb5XQC+Yz4/vFoKwnZG8Cna62QwqTrQxqPsimz8ykPHceFTLNRjY4XwtkVvOl39pUmDkOW1SSBHX8IeFeM+U/uSKvQ5O1VbK96WlZxKBS52AzEeJmvpFINY8Di/lje1nfwG0MqKK3el+DUH X-Received: by 10.42.226.66 with SMTP id iv2mr383018icb.11.1389235424707; Wed, 08 Jan 2014 18:43:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 8 Jan 2014 18:43:24 -0800 (PST) In-Reply-To: <52C9D788.8060606@gmail.com> References: <52C9D788.8060606@gmail.com> From: Lorenzo Colitti Date: Thu, 9 Jan 2014 11:43:24 +0900 Message-ID: Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a113323b8ffee8104ef809309 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: Thu, 09 Jan 2014 02:43:55 -0000 --001a113323b8ffee8104ef809309 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 6, 2014 at 7:07 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > A group of us put this together following a discussion some weeks > ago on the v6ops list about the 64-bit boundary in IPv6 addresses. > Discussion belongs in 6man, please. > Authors, why does the draft say that RFC 4941 says: "[RFC4291] specifies that a unicast address is divided into n bits of subnet prefix followed by (128-n) bits of interface identifier (IID)" but not that it says: "For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long". Cheers, Lorenzo --001a113323b8ffee8104ef809309 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 6, 2014 at 7:07 AM, Brian E Carpenter <brian.e.carpenter= @gmail.com> wrote:
A group of us put this together following a discussion som= e weeks
ago on the v6ops list about the 64-bit boundary in IPv6 addresses.
Discussion belongs in 6man, please.

Aut= hors,

why does the draft say that RFC 4941 says:

"[RFC4291] specifies that a unicast address is= divided into n bits of subnet prefix followed by (128-n) bits of interface= identifier (IID)"

but not that it says:

"Fo= r all unicast addresses, except those that start with the binary value 000,= Interface IDs are required to be 64 bits long".

Cheers,
Lorenzo
--001a113323b8ffee8104ef809309-- From samita.chakrabarti@ericsson.com Wed Jan 8 18:57: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 0918A1AE056 for ; Wed, 8 Jan 2014 18:57:33 -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 M3qkgHSne2CU for ; Wed, 8 Jan 2014 18:57:31 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id C0EE21AE04A for ; Wed, 8 Jan 2014 18:57:30 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-f9-52ce10076832 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 52.94.23183.7001EC25; Thu, 9 Jan 2014 03:57:11 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0347.000; Wed, 8 Jan 2014 21:57:13 -0500 From: Samita Chakrabarti To: Lorenzo Colitti , Mikael Abrahamsson Subject: RE: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 Thread-Topic: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 Thread-Index: AQHO5RSHI47a5UQsiE68Y1syr/NqV5p7SCiAgAAXUQCAAOU+AP//tHeg Date: Thu, 9 Jan 2014 02:57:12 +0000 Message-ID: References: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_ECA43DA70480A3498E43C3471FB2E1F01C13CB48eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXRPuC67wLkgg+nLZS0WdDaxWrw8+57J Yv3pd4wWL5duZXNg8ViwqdRjyZKfTB5/Jz1k8vhy+TNbAEsUl01Kak5mWWqRvl0CV8bzfz+Y CpZkV0zefZitgXFDRhcjJ4eEgInEmobTLBC2mMSFe+vZQGwhgSOMEutnh3UxcgHZyxglfh+9 ywiSYBOwkujo3cMOYosIBErsv/ONtYuRg4NZwFXix3IBkLCwQLDErq8ToUpCJG4fmMIGYbtJ tD5aDraLRUBFYsuMiWBxXgFfiXvfVjND7Gpnkjh+sIkZJMEJNL/50QewBkag476fWsMEYjML iEvcejKfCeJoAYkle84zQ9iiEi8f/2OFsJUlvs95xAJRny+xYvJCJohlghInZz5hmcAoOgvJ qFlIymYhKZsF9pqmxPpd+hAlihJTuh+yQ9gaEq1z5rIjiy9gZF/FyFFanFqWm25ksIkRGHnH JNh0dzDueWl5iFGag0VJnPfLW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYzaHBeuGbiq /7ZJkzYRY3pie/GPr8JBpvDp4kyM9bzrVz0QuXq564CG3BVfg4desjuWbf0kfPWAltuKi7v/ OLd2LTLYWfpJMt7+wYb6+zYVqlVKCfteG/UbbgxVnqu7YLHDj9r2hU84m9+3bS8XUnM0mH04 VFTAXtDjSlzUVcd1W7Ulrr+f1q3EUpyRaKjFXFScCAChtL7DigIAAA== Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 09 Jan 2014 02:57:33 -0000 --_000_ECA43DA70480A3498E43C3471FB2E1F01C13CB48eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSBMb3JlbnpvOg0KDQpNaWthZWw+ICBUaGlzIHdvdWxkIGJlIGEgYmlnIHdpbiwgZXNwZWNp YWxseSBpZiBpdCBjb3VsZCBiZSBkb25lIHdpdGggbWluaW1hbCBjaGFuZ2VzIHRvIHRoZSBjbGll bnRzLg0KDQpZb3UgZG9uJ3QgbmVlZCB0byBtb2RpZnkgTkQgdG8gZG8gdGhhdCwgdGhvdWdoLiBZ b3UgY2FuIGRlZmVuZCBhZ2FpbnN0IHRoYXQgc29ydCBvZiBhdHRhY2sgYnkgaGF2aW5nIHRoZSBO RCBpbXBsZW1lbnRhdGlvbjoNCg0KMS4gUHJpb3JpdGl6ZSBwcmVzZXJ2aW5nIE5EIGNhY2hlIGVu dHJpZXMgb3ZlciBtYWtpbmcgbmV3IGFkZHJlc3MgcmVzb2x1dGlvbiBhdHRlbXB0cy4NCjIuIEds ZWFuIE5EIGNhY2hlIGVudHJpZXMgZnJvbSBEQUQgcGFja2V0cyAoYW5kIGlmIG5lZWQgYmUsIE5T L05BIHBhY2tldHMpLCBhbmQgcHJpb3JpdGl6ZSB0aG9zZSBnbGVhbmVkIGVudHJpZXMgb3ZlciBu ZXcgYWRkcmVzcyByZXNvbHV0aW9uIGF0dGVtcHRzLg0KDQpTb21lIG9mIHRoZXNlIG1lYXN1cmVz IGFyZSBkb2N1bWVudGVkIGluIFJGQyA2NTgzLg0KW1NDPl0NCltTQz5dIEkgdW5kZXJzdGFuZCB0 aGF0IHlvdSBoYXZlIGEgdmlldyBwb2ludC4gIEJ1dCAgdGhlcmUgYXJlICBtYW55IGZvbGtzL3Zl bmRvcnMgd2hvIGhhdmUgZXhwcmVzc2VkIGludGVyZXN0L3N1cHBvcnRlZCB0aGlzIHdvcmssIHNl ZSBhIG5lZWQgdG8gaW1wcm92ZSBORCAgYXMgaXQgaGFzIG9wZXJhdGlvbmFsIGlzc3VlcyBmb3Ig SVB2NiBkZXBsb3ltZW50IG9uIGxhcmdlIHNjYWxlLCB3aXJlbGVzcyBzd2l0Y2hlcywgdmlydHVh bGl6ZWQgZW52aXJvbm1lbnRzLiBSRkMgNjU4MyAobWVudGlvbmVkIGFib3ZlKSBkaXNjdXNzZXMg TkQgb3BlcmF0aW9uYWwgaXNzdWVzIGFuZCB0aXBzIGZvciBpbXBsZW1lbnRhdGlvbi4gVGhlcmUg YXJlIG51bWJlciBvZiBkcmFmdHMsIFJGQyBhbmQgcGllY2VzIGRpc2N1c3NpbmcgaW1wcm92ZW1l bnRzIG9uIGRpZmZlcmVudCBORCB1c2VjYXNlcyBhbmQgc2NlbmFyaW9zLiBJdCBkb2VzIG5vdCBo ZWxwIGltcGxlbWVudGVycyB0byB1bmRlcnN0YW5kIGFuZCBkZXBsb3kgSXB2NiBORCBlYXNpbHkg aW4gbWFueSBzY2VuYXJpb3Mg4oCTIGluY2x1ZGluZyBNMk0sIHdpcmVsZXNzIHBob25lcywgbW9u aXRvcmluZyBjYW1lcmFzIGFuZCBzbyBvbi4gQSByZXZpc2VkL2ltcHJvdmVkIE5EIGlzIG5lZWRl ZCBmb3IgSVB2Ni4NCldlIHN0YXJ0ZWQgb24gdGhpcyBkcmFmdCAgc29tZXRpbWUgYWdvLCBhZnRl ciBhbiBJT1QgSUFCIHdvcmtzaG9wIHdoZXJlICBwZW9wbGUgZmVsdCB0aGF0IGNsZWFybHkgdGhl cmUgaXMgYSBuZWVkIHRvIGNsYXJpZnkgSVB2NiBORCBiZWhhdmlvciB0byAxKSByZWR1Y2UgbXVs dGljYXN0IG1lc3NhZ2VzIDIpIGFsbG93IHJlbW92YWwgb2YgREFEIGluIHNvbWUgc2l0dWF0aW9u cyAzKSBhbGxvdyByZWdpc3RyYXRpb24gb2Ygbm9kZXMgZm9yIHJlbGlhYmxlIE5EIG9wZXJhdGlv biB3aGVuIG11bHRpY2FzdCBpcyByZWR1Y2VkLg0KVGhlcmUgYXJlIHNvbWUgcmVhbCB3aXJlbGVz cyBhbmQgIHdpcmVkICBkZXBsb3ltZW50cyB3aGljaCB3aWxsIGJlbmVmaXQgaWYgdGhlIE5EIHJl Z2lzdHJhdGlvbi9vcHRpbWl6YXRpb24gZm9yIElQdjYgaXMgc3BlY2lmaWVkIGluIG9uZSBkb2N1 bWVudCBhcyBhIHN0YW5kYXJkIHdpdGhvdXQgYWZmZWN0aW5nIHRoZSBsZWdhY3kgTkQgaW1wbGVt ZW50YXRpb25zIG9yIGRlcGxveW1lbnQuIFsgQ2hlY2sgb3V0IHRoZSBhcHBlbmRpeCBzZWN0aW9u XQ0KDQpPdXIgc29sdXRpb24gaXMgbG9va2luZyBpbnRvIG1pbmltYWwgY2hhbmdlcyB0byB0aGUg Y2xpZW50cyBhbmQgbW9zdCBvZiB0aGUgY2hhbmdlcyBhcmUgaW4gdGhlIFJvdXRlciBpbXBsZW1l bnRhdGlvbiBhbmQgIHNvbWUgaW1wbGVtZW50YXRpb25zIGFscmVhZHkgZXhpc3QgdGhyb3VnaCBS RkM2Nzc1IOKAkyBob3dldmVyIHRoYXQgZG9lcyBub3QgZGlyZWN0bHkgYWRkcmVzcyBJUHY2IGxl Z2FjeSBuZXR3b3Jrcy4gU28gdGhlIHB1cnBvc2UgaXMgdG8gcHJvdmlkZSBvcHRpb25zIHRvIGEg c2VjdGlvbiBvZiBJcHY2IGVuYWJsZWQgZGV2aWNlcy9yb3V0ZXJzL3NlcnZlcnMgdGhhdCBjYW4g b3B0aW9uYWxseSBpbXBsZW1lbnQgZWZmaWNpZW50LU5EIGJlaGF2aW9yIHRvIGltcHJvdmUgdGhl aXIgSXB2NiBuZXR3b3JrcyAoc2luZ2xlIGhvcCBMQU4pLg0KDQpJIGtub3cgd2UgY2FuIGNsYXJp ZnkgdGhlc2UgaW4gdGhlIGRvY3VtZW50IGFuZCBpbXByb3ZlIHRoZSB0ZXh0IHRvIGJlIHByZWNp c2UgZ29pbmcgZm9yd2FyZC4NCi1TYW1pdGENCg0KDQoNCg0KDQo= --_000_ECA43DA70480A3498E43C3471FB2E1F01C13CB48eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkhpIExvcmVuem86PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxi cj4NCjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48L3NwYW4+PC9pPjwvYj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TWlrYWVsJmd0OyAmbmJzcDs8L3NwYW4+VGhpcyB3b3Vs ZCBiZSBhIGJpZyB3aW4sIGVzcGVjaWFsbHkgaWYgaXQgY291bGQgYmUgZG9uZSB3aXRoIG1pbmlt YWwgY2hhbmdlcyB0byB0aGUgY2xpZW50cy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+WW91IGRvbid0IG5lZWQgdG8gbW9kaWZ5IE5EIHRvIGRvIHRoYXQsIHRob3VnaC4g WW91IGNhbiBkZWZlbmQgYWdhaW5zdCB0aGF0IHNvcnQgb2YgYXR0YWNrIGJ5IGhhdmluZyB0aGUg TkQgaW1wbGVtZW50YXRpb246PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+MS4gUHJpb3JpdGl6ZSBwcmVzZXJ2aW5nIE5EIGNhY2hlIGVudHJpZXMgb3ZlciBt YWtpbmcgbmV3IGFkZHJlc3MgcmVzb2x1dGlvbiBhdHRlbXB0cy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4yLiBHbGVhbiBORCBjYWNoZSBlbnRyaWVzIGZyb20gREFEIHBhY2tldHMgKGFuZCBpZiBuZWVk IGJlLCBOUy9OQSBwYWNrZXRzKSwgYW5kIHByaW9yaXRpemUgdGhvc2UgZ2xlYW5lZCBlbnRyaWVz IG92ZXIgbmV3IGFkZHJlc3MgcmVzb2x1dGlvbiBhdHRlbXB0cy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Tb21lIG9mIHRoZXNlIG1lYXN1cmVzIGFyZSBk b2N1bWVudGVkIGluIFJGQyA2NTgzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltTQyZn dDtdDQo8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltTQyZndDtdIEkgdW5k ZXJzdGFuZCB0aGF0IHlvdSBoYXZlIGEgdmlldyBwb2ludC4mbmJzcDsgQnV0Jm5ic3A7IHRoZXJl IGFyZSAmbmJzcDttYW55IGZvbGtzL3ZlbmRvcnMgd2hvIGhhdmUgZXhwcmVzc2VkIGludGVyZXN0 L3N1cHBvcnRlZCB0aGlzIHdvcmssIHNlZSBhIG5lZWQgdG8gaW1wcm92ZQ0KIE5EICZuYnNwO2Fz IGl0IGhhcyBvcGVyYXRpb25hbCBpc3N1ZXMgZm9yIElQdjYgZGVwbG95bWVudCBvbiBsYXJnZSBz Y2FsZSwgd2lyZWxlc3Mgc3dpdGNoZXMsIHZpcnR1YWxpemVkIGVudmlyb25tZW50cy4gUkZDIDY1 ODMgKG1lbnRpb25lZCBhYm92ZSkgZGlzY3Vzc2VzIE5EIG9wZXJhdGlvbmFsIGlzc3VlcyBhbmQg dGlwcyBmb3IgaW1wbGVtZW50YXRpb24uIFRoZXJlIGFyZSBudW1iZXIgb2YgZHJhZnRzLCBSRkMg YW5kIHBpZWNlcyBkaXNjdXNzaW5nDQogaW1wcm92ZW1lbnRzIG9uIGRpZmZlcmVudCBORCB1c2Vj YXNlcyBhbmQgc2NlbmFyaW9zLiBJdCBkb2VzIG5vdCBoZWxwIGltcGxlbWVudGVycyB0byB1bmRl cnN0YW5kIGFuZCBkZXBsb3kgSXB2NiBORCBlYXNpbHkgaW4gbWFueSBzY2VuYXJpb3Mg4oCTIGlu Y2x1ZGluZyBNMk0sIHdpcmVsZXNzIHBob25lcywgbW9uaXRvcmluZyBjYW1lcmFzIGFuZCBzbyBv bi4gQSByZXZpc2VkL2ltcHJvdmVkIE5EIGlzIG5lZWRlZCBmb3IgSVB2Ni48bzpwPjwvbzpwPjwv c3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9i PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5XZSBzdGFydGVkIG9uIHRoaXMgZHJhZnQgJm5ic3A7c29tZXRp bWUgYWdvLCBhZnRlciBhbiBJT1QgSUFCIHdvcmtzaG9wIHdoZXJlICZuYnNwO3Blb3BsZSBmZWx0 IHRoYXQgY2xlYXJseSB0aGVyZSBpcyBhIG5lZWQgdG8gY2xhcmlmeSBJUHY2IE5EIGJlaGF2aW9y IHRvIDEpIHJlZHVjZQ0KIG11bHRpY2FzdCBtZXNzYWdlcyAyKSBhbGxvdyByZW1vdmFsIG9mIERB RCBpbiBzb21lIHNpdHVhdGlvbnMgMykgYWxsb3cgcmVnaXN0cmF0aW9uIG9mIG5vZGVzIGZvciBy ZWxpYWJsZSBORCBvcGVyYXRpb24gd2hlbiBtdWx0aWNhc3QgaXMgcmVkdWNlZC48bzpwPjwvbzpw Pjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVyZSBhcmUgc29tZSByZWFsIHdp cmVsZXNzIGFuZCAmbmJzcDt3aXJlZCAmbmJzcDtkZXBsb3ltZW50cyB3aGljaCB3aWxsIGJlbmVm aXQgaWYgdGhlIE5EIHJlZ2lzdHJhdGlvbi9vcHRpbWl6YXRpb24gZm9yIElQdjYgaXMgc3BlY2lm aWVkIGluIG9uZSBkb2N1bWVudCBhcyBhDQogc3RhbmRhcmQgd2l0aG91dCBhZmZlY3RpbmcgdGhl IGxlZ2FjeSBORCBpbXBsZW1lbnRhdGlvbnMgb3IgZGVwbG95bWVudC4gWyBDaGVjayBvdXQgdGhl IGFwcGVuZGl4IHNlY3Rpb25dPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ T3VyIHNvbHV0aW9uIGlzIGxvb2tpbmcgaW50byBtaW5pbWFsIGNoYW5nZXMgdG8gdGhlIGNsaWVu dHMgYW5kIG1vc3Qgb2YgdGhlIGNoYW5nZXMgYXJlIGluIHRoZSBSb3V0ZXIgaW1wbGVtZW50YXRp b24gYW5kJm5ic3A7IHNvbWUgaW1wbGVtZW50YXRpb25zIGFscmVhZHkNCiBleGlzdCB0aHJvdWdo IFJGQzY3NzUg4oCTIGhvd2V2ZXIgdGhhdCBkb2VzIG5vdCBkaXJlY3RseSBhZGRyZXNzIElQdjYg bGVnYWN5IG5ldHdvcmtzLiBTbyB0aGUgcHVycG9zZSBpcyB0byBwcm92aWRlIG9wdGlvbnMgdG8g YSBzZWN0aW9uIG9mIElwdjYgZW5hYmxlZCBkZXZpY2VzL3JvdXRlcnMvc2VydmVycyB0aGF0IGNh biBvcHRpb25hbGx5IGltcGxlbWVudCBlZmZpY2llbnQtTkQgYmVoYXZpb3IgdG8gaW1wcm92ZSB0 aGVpciBJcHY2IG5ldHdvcmtzDQogKHNpbmdsZSBob3AgTEFOKS48bzpwPjwvbzpwPjwvc3Bhbj48 L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9i PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5JIGtub3cgd2UgY2FuIGNsYXJpZnkgdGhlc2UgaW4gdGhlIGRv Y3VtZW50IGFuZCBpbXByb3ZlIHRoZSB0ZXh0IHRvIGJlIHByZWNpc2UgZ29pbmcgZm9yd2FyZC48 bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxp PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tU2FtaXRhPG86cD48 L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwv Yj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_ECA43DA70480A3498E43C3471FB2E1F01C13CB48eusaamb103erics_-- From brian.e.carpenter@gmail.com Wed Jan 8 18:58: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 5FCC01AE084 for ; Wed, 8 Jan 2014 18:58:42 -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 1T9iKsMvWoCn for ; Wed, 8 Jan 2014 18:58:41 -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 2A9951AE054 for ; Wed, 8 Jan 2014 18:58:41 -0800 (PST) Received: by mail-pb0-f42.google.com with SMTP id uo5so2427459pbc.1 for ; Wed, 08 Jan 2014 18:58:32 -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=R1fuEJGQZwbKn1/95c792F/MFzChH6Rk5w+o8gpDPw0=; b=AeT5p7rhhU302Y4y2YgZy6Gybv1VUBFj1nMmNseWXp/WDVSWhTuk5ZCmabj3+euklV xjD1usm/k+LWzoqCt8EtesOXkIOzIBfaTKI2EYalSQe7XQbFHBF1dU9OL8MTGf1RwNaq cmlSIJCRtPruPg808lcs7vVlFl7gNxv/VSQPuBfp5MDNl4XvASI1J1zW1bRgvy+E4kFd FzsLkMFsdMuyXuqfcEVo7QbbfawYMnzJEVyBvGnDemJI4eWqqtBPg0ulefM1f0zezOY1 aVnz7cvzXEccGEaxdKBTebxY9PzTUQ3/Vdvsq/k2H2Kdb31teJsuNuTKRAFAX9ZmXf6n bEyQ== X-Received: by 10.68.240.103 with SMTP id vz7mr744328pbc.11.1389236311952; Wed, 08 Jan 2014 18:58:31 -0800 (PST) Received: from [192.168.178.21] (81.196.69.111.dynamic.snap.net.nz. [111.69.196.81]) by mx.google.com with ESMTPSA id qp15sm5895485pbb.2.2014.01.08.18.58.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Jan 2014 18:58:31 -0800 (PST) Message-ID: <52CE105E.4050102@gmail.com> Date: Thu, 09 Jan 2014 15:58:38 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] References: <52C9D788.8060606@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: Thu, 09 Jan 2014 02:58:42 -0000 On 09/01/2014 15:43, Lorenzo Colitti wrote: > On Mon, Jan 6, 2014 at 7:07 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> A group of us put this together following a discussion some weeks >> ago on the v6ops list about the 64-bit boundary in IPv6 addresses. >> Discussion belongs in 6man, please. >> > > Authors, > > why does the draft say that RFC 4941 says: > > "[RFC4291] specifies that a unicast address is divided into n bits of > subnet prefix followed by (128-n) bits of interface identifier (IID)" > > but not that it says: > > "For all unicast addresses, except those that start with the binary value > 000, Interface IDs are required to be 64 bits long". Actually that (truncated) sentence is obsoleted by draft-ietf-6man-ug which is in the RFC queue. New version: "For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long. If derived from an IEEE MAC-layer address, they must be constructed in Modified EUI-64 format." But yes, we should mention that. We reviewed a lot of RFCs and there are probably other things we missed too. Brian From lorenzo@google.com Wed Jan 8 19:20: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 9428C1AE0AB for ; Wed, 8 Jan 2014 19:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, 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 b1HHZs4Pt9VG for ; Wed, 8 Jan 2014 19:20:00 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 195901AE0A7 for ; Wed, 8 Jan 2014 19:19:59 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id c10so14964898igq.4 for ; Wed, 08 Jan 2014 19:19:50 -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=9MUohmd5IrytueIZ0fmzY0dWm1ogV79fnnfMngUMKbY=; b=R1VBIvLcKniQ3IE/xnWjGhwnIn30cjzYNOOoPJsQArLDhwlB2ekz9P8pqpX8hqmfUP pVB8uiEX2WlMbNqnA9zAvHLcXriy+NM/I2ESVFNfS+SySW34y6LSkp2rByOzFpaToarj Y2vMi58Y0De+HbGNm1k9BZnHlmiJ5ze6hyjbSmpAYvWB9eiJb3frX0Kr2uUL9FQraDaU kZmTsmu39Vb4BUmF241P3bhL5GjJVYMpAOND1f46CKNSumiCiXvsUo8c2uJgOYnME/mI +Oq2Zal4a3Sp0hPsSfBnY8ckKE9594kFi4OPQN57PfSHNgU6GT5BzO/s60HGKVye6fA3 eT0g== 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=9MUohmd5IrytueIZ0fmzY0dWm1ogV79fnnfMngUMKbY=; b=UTiexjJCkcMs/vurL6NVgJ96mZ0SJtyD1FnXZUb8n2OTLPEp5/z4pBdGgvfqzgZDVH Et0qqWrQHYHp3gOkLeyUtARVp06o+XhZiDcwGvahNIXMgo50CFvUFHW/4YHQCSmiWOzz pZ/eExojIcfsPMbTwdLZWqiDZw67oNmzeXcGxMSMADsBwN+d4WWomqMdvS9Lxbev7YeY GLYZJcOcsCEvYP53p8HiaMQUGaZtMl/33E3gYwA1RMFbWBDxtn12ALim3cFNanXcFK1h zfEQCpZFPgZ/UrIlOrnriFq6n52DTdohZgwKE3kCH7pHLtYcODgYOi78VTa3pISj4Ia7 /m8g== X-Gm-Message-State: ALoCoQnV7JeNcUK0Fc2QHaDjpFDbBsNkzjUHII0OHFulztIoY4C3M9savSLPQomfVXzrokPShrKzJdZ1qQL6lMnAayM1rAhynAMUNFO19Xk5ObvZeg8d+INBPDJzx6uKX+JK64z+yu/oUHjXJQaW357kB/Wo9MGaUfGPGt646AJU77J4zFSbjJD3HQo/ZUiYMhoI2N9GOYEF X-Received: by 10.50.176.137 with SMTP id ci9mr36141498igc.31.1389237590532; Wed, 08 Jan 2014 19:19:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 8 Jan 2014 19:19:30 -0800 (PST) In-Reply-To: <52CE105E.4050102@gmail.com> References: <52C9D788.8060606@gmail.com> <52CE105E.4050102@gmail.com> From: Lorenzo Colitti Date: Thu, 9 Jan 2014 12:19:30 +0900 Message-ID: Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] To: Brian E Carpenter Content-Type: multipart/alternative; boundary=089e0111e0da180fad04ef81154e 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: Thu, 09 Jan 2014 03:20:01 -0000 --089e0111e0da180fad04ef81154e Content-Type: text/plain; charset=UTF-8 On Thu, Jan 9, 2014 at 11:58 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > "For all unicast addresses, except those that start with the binary value > > 000, Interface IDs are required to be 64 bits long". > > Actually that (truncated) sentence is obsoleted by draft-ietf-6man-ug which > is in the RFC queue. New version: > > "For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long. If derived > ... which is exactly the sentence I cited, right? I did look at draft-ietf-6man-ug before I blurted out, you know :-) --089e0111e0da180fad04ef81154e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 9, 2014 at 11:58 AM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
> "For all unica= st addresses, except those that start with the binary value
> 000, Interface IDs are required to be 64 bits long".

Actually that (truncated) sentence is obsoleted by draft-ietf-6= man-ug which
is in the RFC queue. New version:

=C2=A0 =C2=A0"For all unicast addresses, except those that start with = the binary
=C2=A0 =C2=A0 value 000, Interface IDs are required to be 64 bits lon= g. If derived

... which is exactly the sentence I cited,= right? I did look at draft-ietf-6man-ug before I blurted out, you know :-)=
--089e0111e0da180fad04ef81154e-- From lorenzo@google.com Wed Jan 8 19:46: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 AAD7C1AE0F4 for ; Wed, 8 Jan 2014 19:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, 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 XttGcG8dM2PS for ; Wed, 8 Jan 2014 19:46:02 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3181AE0B1 for ; Wed, 8 Jan 2014 19:46:01 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id e14so2875071iej.26 for ; Wed, 08 Jan 2014 19:45:52 -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=x8HlBQwf26ZRg5M7BcmvmIW0YZz4DSkmW1u1Iwf3gog=; b=NjIvu/iC3aTBI20dZyLiXLhv8rn7pogZ/leleADvz1zDrg/sod2FCtcbLGh/Ry3M8U 3o+1U920zISIEoiPci6GMaxMVQYOdZ9a8gNCIPRLQAYySvgeCo9LYRJ83oU7XJdvt2E2 y3YZ+5rzlV0/6Je+e3JpMdgYozijGVOlnYeh3FnHBbQOBLfcNmwQxez+PQwtWoiqEsOF giHTXIwzRtrIpo1odsEB5P9G/osQwQ8PcbsUi7tvrcg3aP32dCsReLSx+mhSP4f6eOP/ oa+wCX+9prWgJ9/rneQ5/aFsKpasykWXiBuvVxdzm1vKgSTp7EPwtyWo6Kzb3oXK/gx9 8lgQ== 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=x8HlBQwf26ZRg5M7BcmvmIW0YZz4DSkmW1u1Iwf3gog=; b=lH6f8iKlUS/3+p53Gyr98XpgLnx+avmQofgsGldGNsUHHNWlAevyezSIV/3ymN9qQE aSxcP1cLc3SnIohodEkh3IwRbz/6IEni8z5PpFAExRsyOwwNHugIy4qfYvajCHgrRgiG jnyaWEWU95bxgfALW62RNvGxdVCBs/uyOKixEhrbAMvoqcgZxAqlS+AKfprL58OkVF9i MQ4sPqLRx8ndXjbag9aEDfJMtr+PTLw7m68mhRqeU7sVXocUXNLXUwywd2S+M0nVnhH+ qLD2l1rq3Uaia8rtvJCxCqROrGkSs0is51uDdjA1GUU1diEKLaMIvZMOH22otxOO/1ns zHwg== X-Gm-Message-State: ALoCoQnNWjVroIW//23vnmjGWdVFOkKJ8XDiquYP5BB93nscFmmFlukzNU8jXBJQJQghfD9fwzotURhlOZ/AGZ/iM0I2389Np0z7y6+yAfNn6qbhla/syPF3bFgORFuYIha2lqdZFMW/5U0VtyYG2fRWPPnCa8wrKbsF7Kd2Vvw3ZIU3MIFMLpwqWumVZ5gvGcsRfqjxNIxU X-Received: by 10.50.61.137 with SMTP id p9mr36180282igr.45.1389239152505; Wed, 08 Jan 2014 19:45:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 8 Jan 2014 19:45:32 -0800 (PST) In-Reply-To: References: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> From: Lorenzo Colitti Date: Thu, 9 Jan 2014 12:45:32 +0900 Message-ID: Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 To: Samita Chakrabarti Content-Type: multipart/alternative; boundary=047d7bdca5dc319d4904ef817221 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 09 Jan 2014 03:46:04 -0000 --047d7bdca5dc319d4904ef817221 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jan 9, 2014 at 11:57 AM, Samita Chakrabarti < samita.chakrabarti@ericsson.com> wrote: > *A revised/improved ND is needed for IPv6.* > > *We started on this draft sometime ago, after an IOT IAB workshop where > people felt that clearly there is a need to clarify IPv6 ND behavior to = 1) > reduce multicast messages 2) allow removal of DAD in some situations 3) > allow registration of nodes for reliable ND operation when multicast is > reduced.* > Samita, I think statements like "is needed" and "people felt" are not enough to justify substantial changes to a core part of the protocol. The rationale should be clearly stated in technical terms in the document, and should be convincing on its own merits. For this sort of changes to core protocols, the bar should be set very high. > *There are some real wireless and wired deployments which will benefit > if the ND registration/optimization for IPv6 is specified in one document > as a standard without affecting the legacy ND implementations or > deployment. [ Check out the appendix section]* > Sorry, I didn't provide comments on the rationale in the appendix. Here are some comments now: 1. Datacenter deployments. Really? A datacenter is a place where machines have high-bandwidth interconnects and plentiful CPU because they are engaged in production activities - otherwise you don't build a datacenter. I cannot imagine that even if a datacenter at trough consumes 1/10 of the compute power of one at peak, that the energy saved by efficient ND is even a drop in the ocean of cooling, power conversion losses, energy used by network equipment, etc. If a machine in sleep mode cannot receive ND packets, then it cannot receive unicast packets either and there's no point proxying ND requests for it. Remember - ND is only performed *when someone wants to send you a packet anyway*. If the machine *can* receive ND packets, then presumably going into and out of sleep mode is fast, so to save energy it's enough to ensure that ND is only triggered rarely - which there are ways to do as listed in my previous email. 2. NUD scaling on the BNG. What's the use case here? Is it to reduce the NS messages sent to the CPE to make it easier for the CPU? Is there any evidence that the load is significant enough to care, and if it is, that something like this can't just be done on the linecards? As for wired and wireless devices, I think I addressed that point in my previous email. 3. M2M. Agreed, but that's what 6lowpan is for, right? 4. Wifi. I already addressed this, but let me address it again. a) Do you run IPv4? If you run out of multicast bandwidth, IPv4 is broken. b) In large wifi networks, which is the only place that this is really an issue exists, the infrastructure is usually more than capable of converting multicast to unicast. c) If the concern is power draw on devices, then the wifi chipsets of those devices are are receiving packets all the time, right? There are constant beacons, and so on. So it's just a matter of telling the wifi chipsets to drop packets that aren't addressed to multicast addresses that the device hasn't registered for. Wifi chipsets already have RX filtering that can do this. > *Our solution is looking into minimal changes to the clients and most of > the changes are in the Router implementation and some implementations > already exist through RFC6775 =E2=80=93 however that does not directly ad= dress IPv6 > legacy networks.* > By definition, legacy networks can't use new technology. If what you mean is "non-6LowPAN IPv6 networks", then the question is - do we really need such a level of energy efficiency in these networks? If those networks happen to run IPv4 - which basically *all* hosts on broadcast networks do, then the answer is a clear no - because ARP is much more wasteful than ND. When we move to IPv6-only, then we should definitely reconsider this optimization, but until then, there will be no benefit. Cheers, Lorenzo --047d7bdca5dc319d4904ef817221 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 9, 2014 at 11:57 AM, Samita Chakrabarti <samita.chak= rabarti@ericsson.com> wrote:

A revised/improved = ND is needed for IPv6.

We started on this = draft =C2=A0sometime ago, after an IOT IAB workshop where =C2=A0people felt= that clearly there is a need to clarify IPv6 ND behavior to 1) reduce multicast messages 2) allow removal of DAD in some situations 3) allow reg= istration of nodes for reliable ND operation when multicast is reduced.


Samita,

I think statements like "i= s needed" and "people felt" are not enough to justify substa= ntial changes to a core part of the protocol. The rationale should be clear= ly stated in technical terms in the document, and should be convincing on i= ts own merits. For this sort of changes to core protocols, the bar should b= e set very high.
=C2=A0

=

There are some real= wireless and =C2=A0wired =C2=A0deployments which will benefit if the ND re= gistration/optimization for IPv6 is specified in one document as a standard without affecting the legacy ND implementations or deployment. [ = Check out the appendix section]

<= /div>

Sorry, I didn't provide com= ments on the rationale in the appendix. Here are some comments now:

1. Datacenter deployments. Really? A datacenter is a pl= ace where machines have high-bandwidth interconnects and plentiful CPU beca= use they are engaged in production activities - otherwise you don't bui= ld a datacenter. I cannot imagine that even if a datacenter at trough consu= mes 1/10 of the compute power of one at peak, that the energy saved by effi= cient ND is even a drop in the ocean of cooling, power conversion losses, e= nergy used by network equipment, etc.

If a machine in sleep mode cannot receive ND packets, t= hen it cannot receive unicast packets either and there's no point proxy= ing ND requests for it. Remember - ND is only performed *when someone wants= to send you a packet anyway*. If the machine *can* receive ND packets, the= n presumably going into and out of sleep mode is fast, so to save energy it= 's enough to ensure that ND is only triggered rarely - which there are = ways to do as listed in my previous email.

2. NUD scaling on the BNG. What's the use case here= ? Is it to reduce the NS messages sent to the CPE to make it easier for the= CPU? Is there any evidence that the load is significant enough to care, an= d if it is, that something like this can't just be done on the linecard= s? As for wired and wireless devices, I think I addressed that point in my = previous email.

3. M2M. Agreed, but that's what 6lowpan is for, rig= ht?

4. Wifi. I already addressed this, but let me = address it again. a) Do you run IPv4? If you run out of multicast bandwidth= , IPv4 is broken. b) In large wifi networks, which is the only place that t= his is really an issue exists, the infrastructure is usually more than capa= ble of converting multicast to unicast. c) If the concern is power draw on = devices, then the wifi chipsets of those devices are are receiving packets = all the time, right? There are constant beacons, and so on. So it's jus= t a matter of telling the wifi chipsets to drop packets that aren't add= ressed to multicast addresses that the device hasn't registered for. Wi= fi chipsets already have RX filtering that can do this.
=C2=A0

= =C2=A0Our solution is looking into minimal changes to the clients and mo= st of the changes are in the Router implementation and=C2=A0 some implement= ations already exist through RFC6775 =E2=80=93 however that does not directly address IPv= 6 legacy networks.


By definition, legacy networks can't use= new technology. If what you mean is "non-6LowPAN IPv6 networks",= then the question is - do we really need such a level of energy efficiency= in these networks?

If those networks happen to run IPv4 - which basically = *all* hosts on broadcast networks do, then the answer is a clear no - becau= se ARP is much more wasteful than ND. When we move to IPv6-only, then we sh= ould definitely reconsider this optimization, but until then, there will be= no benefit.

Cheers,
Lorenzo=C2=A0
--047d7bdca5dc319d4904ef817221-- From swmike@swm.pp.se Wed Jan 8 22:09: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 440171AD72A for ; Wed, 8 Jan 2014 22:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.538, 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 gEk0Vo8Qn6_7 for ; Wed, 8 Jan 2014 22:09:23 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 156E01ACCF5 for ; Wed, 8 Jan 2014 22:09:23 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3E5079C; Thu, 9 Jan 2014 07:09:13 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 344C89A; Thu, 9 Jan 2014 07:09:13 +0100 (CET) Date: Thu, 9 Jan 2014 07:09:13 +0100 (CET) From: Mikael Abrahamsson To: Lorenzo Colitti Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 In-Reply-To: Message-ID: References: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 09 Jan 2014 06:09:24 -0000 On Thu, 9 Jan 2014, Lorenzo Colitti wrote: > You don't need to modify ND to do that, though. You can defend against that > sort of attack by having the ND implementation: > > 1. Prioritize preserving ND cache entries over making new address > resolution attempts. > 2. Glean ND cache entries from DAD packets (and if need be, NS/NA packets), > and prioritize those gleaned entries over new address resolution attempts. > > Some of these measures are documented in RFC 6583. If I do that, can I instantly drop packets not in my ND table already? (or my table of 1 and 2 above)? If not, I don't consider it a complete solution. -- Mikael Abrahamsson email: swmike@swm.pp.se From lorenzo@google.com Wed Jan 8 22:22: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 2F6111AD8F3 for ; Wed, 8 Jan 2014 22:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, 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 iuLbdpajwfvL for ; Wed, 8 Jan 2014 22:22:48 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 044FB1ACCDC for ; Wed, 8 Jan 2014 22:22:47 -0800 (PST) Received: by mail-ig0-f177.google.com with SMTP id uy17so6720911igb.4 for ; Wed, 08 Jan 2014 22:22:38 -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=QkFYrHtBOkirS2SSyeni+Kf8iQ9OZ+bED1fXk2itNzg=; b=edkXtzh7D4v/qr3o8lkJ7MD8Yb+hsp5DkuO0q6gwpqndSLT/m1IiY3Z1CCeoKeWP9C 5AGd97tjgM8L3oAuKjE2kw7RJKolK/+kf/6kwsUB+SLVLfypL4XC547/69hbxvmoFauc dw4HHVAt0RoYZIuJahW3eHOaIaZMg+8DnF/zA9dLXYRGQHPKG4hQZhKK5zxagj+GAK/2 3GWIOHurs7AgRdfu9nwAkJG7CZ551aVCQJ9G6o6+VqEaG7Cx1eSkHeG4+9vD1CuFy2pZ 6iseh0NjhciC805x9IcNuVKkOPf0kwnlRazJHLX+QnCci0De6Rto79K8WfMARfoggV+h BdYA== 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=QkFYrHtBOkirS2SSyeni+Kf8iQ9OZ+bED1fXk2itNzg=; b=XVgMWJM55s2GQQflsA8FpCz08vhAPp2qa5xbLa4I4GptT7kTgG0RNGh3aD3pj6YrKL FaPxeqo1szd5yb9LXXUkfFobu8G5+1h/WiwoT8i3aKiHtjwXFiYxNMazbyMpDcuM+YTt LjdDecxrBIQL4uSwaT1VGUEqB6A4WeFPsSiUPtjFG57fSBtgBAGTyH8muUFF4zGt7KoE g/TqoMqGvfsoI/vJO80pmb1DqBEV9bCDlYJ2v3v5Skd0uHw56sAvXIBWTDGSkB6hBey4 GjPxkPQBjeCUOhnnKHhVmxel3sXsCKV1wnRR751Fo0+wbAOQYsIMS/L/7Kwlo/C29Bja 3voQ== X-Gm-Message-State: ALoCoQkLi/8xKvIa+Evs36ZmnVDO7m69rMcNjeN3ivti9bi+q41N3gyCGX4R4Bc6MV5FXeHrA23/irZ2gvJzBpeCE/QHi34RZYaE1X80QLtphp9EtcQMWqEm5lsdkfrTPd2mG99sP5AZrlSxKKSSrzdbGa3BJQs8gEcGJd7vrdN0Nqd2Vo2Ug0QfuGFBftCj6OUm0m1B+kEF X-Received: by 10.43.71.65 with SMTP id yj1mr983973icb.2.1389248558523; Wed, 08 Jan 2014 22:22:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 8 Jan 2014 22:22:18 -0800 (PST) In-Reply-To: References: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> From: Lorenzo Colitti Date: Thu, 9 Jan 2014 15:22:18 +0900 Message-ID: Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=bcaec51f96cfd602d604ef83a274 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 09 Jan 2014 06:22:50 -0000 --bcaec51f96cfd602d604ef83a274 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 9, 2014 at 3:09 PM, Mikael Abrahamsson wrote: > You don't need to modify ND to do that, though. You can defend against that >> sort of attack by having the ND implementation: >> >> 1. Prioritize preserving ND cache entries over making new address >> resolution attempts. >> 2. Glean ND cache entries from DAD packets (and if need be, NS/NA >> packets), >> and prioritize those gleaned entries over new address resolution attempts. >> >> Some of these measures are documented in RFC 6583. >> > > If I do that, can I instantly drop packets not in my ND table already? (or > my table of 1 and 2 above)? > > If not, I don't consider it a complete solution. I'm afraid I don't understand the question. You can't "just drop packets not in your ND table already" - otherwise you won't be able to talk to a new host that just joined the link. What I believe you can do is, even when you are under full-scale attack, allow the following to work: 1. Communications to and from devices in your table keep working. 2. New directly-connected devices can make it into your neighbour cache. Is there something else would you want to do? --bcaec51f96cfd602d604ef83a274 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 9, 2014 at 3:09 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
You don't need to modify ND to do that, though. You can defend against = that
sort of attack by having the ND implementation:

1. Prioritize preserving ND cache entries over making new address
resolution attempts.
2. Glean ND cache entries from DAD packets (and if need be, NS/NA packets),=
and prioritize those gleaned entries over new address resolution attempts.<= br>
Some of these measures are documented in RFC 6583.

If I do that, can I instantly drop packets not in my ND table already? (or = my table of 1 and 2 above)?

If not, I don't consider it a complete solution.

<= /div>
I'm afraid I don't understand the question. You can't= "just drop packets not in your ND table already" - otherwise you= won't be able to talk to a new host that just joined the link. What I = believe you can do is, even when you are under full-scale attack, allow the= following to work:

1. Communications to and from devices in your table kee= p working.
2. New directly-connected devices can make it into you= r neighbour cache.

Is there something else would y= ou want to do?
--bcaec51f96cfd602d604ef83a274-- From swmike@swm.pp.se Wed Jan 8 23:05: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 5F57E1AE030 for ; Wed, 8 Jan 2014 23:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.538, 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 SU3i7asiUhhQ for ; Wed, 8 Jan 2014 23:05:44 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id CD6791ADD9A for ; Wed, 8 Jan 2014 23:05:43 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 18CCF9C; Thu, 9 Jan 2014 08:05:34 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1457C9A; Thu, 9 Jan 2014 08:05:34 +0100 (CET) Date: Thu, 9 Jan 2014 08:05:34 +0100 (CET) From: Mikael Abrahamsson To: Lorenzo Colitti Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 In-Reply-To: Message-ID: References: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 09 Jan 2014 07:05:45 -0000 On Thu, 9 Jan 2014, Lorenzo Colitti wrote: > I'm afraid I don't understand the question. You can't "just drop packets > not in your ND table already" - otherwise you won't be able to talk to a > new host that just joined the link. What I believe you can do is, even > when you are under full-scale attack, allow the following to work: If you glean the DAD packet the host most likely will emit, then that works around the problem. > 1. Communications to and from devices in your table keep working. > 2. New directly-connected devices can make it into your neighbour cache. > > Is there something else would you want to do? No, that is exactly what I want to do, but I don't want to start doing discovery because I received a packet from an external source to an address on my LAN I don't currently have any decent knowledge of that it is in use. That knowledge might come from seeing a DAD packet or some other mechanism. -- Mikael Abrahamsson email: swmike@swm.pp.se From lorenzo@google.com Wed Jan 8 23:18: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 1F4641AE0A0 for ; Wed, 8 Jan 2014 23:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, 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 InkogEprptDX for ; Wed, 8 Jan 2014 23:18:07 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB071AE098 for ; Wed, 8 Jan 2014 23:18:06 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id u16so700192iet.18 for ; Wed, 08 Jan 2014 23:17:57 -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=Ux35qYbEmHRC5bVMO1lpw/icUmS03mcJ6ca1fIuyBGo=; b=dghOZP+8xgt0d/v9eYSfkcD64WoTAC4zUKl5RsJ9mHX8nw+JmBKrlrMGFxC5ymKK4x xXwluCzdFVdmYAEi+E//CSyCExcs6PtY8A4EEV7EuCg8IW+yVyCFZsbJFa0S91Q7nkNg 9x4Pa1H+QPQlIwtPHeXq5xVwSXilAvKJrBgWNLV7onIeQN5W3mlNmJZVNhoaucJdugKC O1WBOtCfnzdr0GJsSVpYxRdWsbEI3PSOCzQBg52HJkLKywfYTadsPVSYo6nTSVmJc31P 9JmgLlqPsRNcNL7nFevo7g6LBzQ3hDdKutxgzD9c4FdkkKpxA1cwkhWBZZ9CyXg7fajf K6nA== 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=Ux35qYbEmHRC5bVMO1lpw/icUmS03mcJ6ca1fIuyBGo=; b=lq/U88B++LqpYLnLLjeEtZuBOPMfqjuBrhLIruTnbVZd4Kgijc5nQ02k02nUe2wgrJ 0CmV1ZH40kW1NY9FiRy240Q7AtM8Ub19554/JIYIP3qH3gQnGc8yGEkASHec1/4IncJz NOfIxBqboc2KRcqmDpomHVFibI0yfj1KyHuIkwBDNoaIVH5NHpdkO1GdxNeue4jB1SMZ b4Cm1Ck9ageO10MSnherhaZi4WVeve/b6lNS7Dnp/8GqLWilSK+EyBQj6eooctBWtoR3 bjiNY2bY9m5KzLA9AQQFBz7LOtTcHbbWdq51ML03w8HBODvlmHJrswPuNY5kBBUEWy+i q0QQ== X-Gm-Message-State: ALoCoQkb5S0EVWwlA5Ebkbp2tSlqJDphL7EiV+2/b2AfcFCUzKbmQsWRM2OCaWvxsqgEHqDjLOsi6QZFktiROPtqoLTxgnKs5EdAntnd4F7TOeUA7QPvbRictde9YvvZK88OuF3stdcZxAALIJ2FJgWnYIFTGi1MMEWgOH46YJIgUFkUhBLdYEthduNHCW+BnNp8gDt5VDL/ X-Received: by 10.43.71.65 with SMTP id yj1mr1147635icb.2.1389251877567; Wed, 08 Jan 2014 23:17:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 8 Jan 2014 23:17:37 -0800 (PST) In-Reply-To: References: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> From: Lorenzo Colitti Date: Thu, 9 Jan 2014 16:17:37 +0900 Message-ID: Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=bcaec51f96cfaab1f004ef84684c Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 09 Jan 2014 07:18:09 -0000 --bcaec51f96cfaab1f004ef84684c Content-Type: text/plain; charset=UTF-8 On Thu, Jan 9, 2014 at 4:05 PM, Mikael Abrahamsson wrote: > >> I'm afraid I don't understand the question. You can't "just drop packets >> not in your ND table already" - otherwise you won't be able to talk to a >> new host that just joined the link. What I believe you can do is, even when >> you are under full-scale attack, allow the following to work: >> > > If you glean the DAD packet the host most likely will emit, then that > works around the problem. Or the RSes which it also most likely will emit (and, with draft-6man-resilient-rs, which it will continue to emit until you send it an RA), yes. > 1. Communications to and from devices in your table keep working. >> 2. New directly-connected devices can make it into your neighbour cache. >> >> Is there something else would you want to do? >> > > No, that is exactly what I want to do, So if that's what you want to do, then I think you can do it with the current ND protocol, even if you are under full-scale attack, with the implementation optimizations I described (gleaning and prioritization). > but I don't want to start doing discovery because I received a packet from > an external source to an address on my LAN I don't currently have any > decent knowledge of that it is in use. > Why not? What's the downside of sending out an NS for an address that's not there? You consume an ND cache slot for the incomplete entry, but if you use the optimizations you'll always have enough space to avoid a DoS scenario. --bcaec51f96cfaab1f004ef84684c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 9, 2014 at 4:05 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:

I'm afraid I don't understand the question. You can't "= ;just drop packets not in your ND table already" - otherwise you won&#= 39;t be able to talk to a new host that just joined the link. What I believ= e you can do is, even when you are under full-scale attack, allow the follo= wing to work:

If you glean the DAD packet the host most likely will emit, then that works= around the problem.

Or the RSes which it a= lso most likely will emit (and, with draft-6man-resilient-rs, which it will= continue to emit until you send it an RA), yes.
=C2=A0
1. Communications to and from devices in your table keep working.
2. New directly-connected devices can make it into your neighbour cache.
Is there something else would you want to do?

No, that is exactly what I want to do,

So i= f that's what you want to do, then I think you can do it with the curre= nt ND protocol, even if you are under full-scale attack, with the implement= ation optimizations I described (gleaning and prioritization).
=C2=A0
but I don't want to start doing disc= overy because I received a packet from an external source to an address on = my LAN I don't currently have any decent knowledge of that it is in use= .

Why not? What's the downside of sendin= g out an NS for an address that's not there? You consume an ND cache sl= ot for the incomplete entry, but if you use the optimizations you'll al= ways have enough space to avoid a DoS scenario.
--bcaec51f96cfaab1f004ef84684c-- From swmike@swm.pp.se Wed Jan 8 23: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 1066A1AE08E for ; Wed, 8 Jan 2014 23:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.538, 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 UPdRYZB0KWnA for ; Wed, 8 Jan 2014 23:57:39 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id E6BB71ADF95 for ; Wed, 8 Jan 2014 23:57:38 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D36F89C; Thu, 9 Jan 2014 08:57:28 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CD75C9A; Thu, 9 Jan 2014 08:57:28 +0100 (CET) Date: Thu, 9 Jan 2014 08:57:28 +0100 (CET) From: Mikael Abrahamsson To: Lorenzo Colitti Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 In-Reply-To: Message-ID: References: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 09 Jan 2014 07:57:40 -0000 On Thu, 9 Jan 2014, Lorenzo Colitti wrote: > Why not? What's the downside of sending out an NS for an address that's > not there? You consume an ND cache slot for the incomplete entry, but if > you use the optimizations you'll always have enough space to avoid a DoS > scenario. Because potentially this would cause hundreds or thousands of NS multicast packets on the LAN per second in a ddos scenario? If we can avoid the router having to learn anything by means of external packet triggers, I think it would be a big win. -- Mikael Abrahamsson email: swmike@swm.pp.se From otroan@employees.org Thu Jan 9 01:38:35 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 7DE961AE157 for ; Thu, 9 Jan 2014 01:38:35 -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, 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 iFDcRTu7beoQ for ; Thu, 9 Jan 2014 01:38:34 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 549A91AE160 for ; Thu, 9 Jan 2014 01:38:29 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIttzlKQ/khL/2dsb2JhbABZgws4uhqBDRZ0giUBAQECAQF5BQsLDgouVwYTGwOHXggNxHoXjwUHgySBEwSQM5l5gy47 X-IronPort-AV: E=Sophos;i="4.95,630,1384300800"; d="asc'?scan'208";a="3376606" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 09 Jan 2014 09:38:19 +0000 Received: from dhcp-lys02-vla252-10-147-116-56.cisco.com (dhcp-lys02-vla252-10-147-116-56.cisco.com [10.147.116.56]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s099cH2o027322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jan 2014 09:38:18 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_94E8FEDD-DE7E-42FA-9044-CB664383ECB3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 From: Ole Troan In-Reply-To: Date: Thu, 9 Jan 2014 10:38:16 +0100 Message-Id: <27F0E5E5-50C1-4B92-AA4F-A849BA10FC9C@employees.org> References: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1827) Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 09 Jan 2014 09:38:35 -0000 --Apple-Mail=_94E8FEDD-DE7E-42FA-9044-CB664383ECB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 09 Jan 2014, at 8:57 , Mikael Abrahamsson wrote: > On Thu, 9 Jan 2014, Lorenzo Colitti wrote: >=20 >> Why not? What's the downside of sending out an NS for an address = that's not there? You consume an ND cache slot for the incomplete entry, = but if you use the optimizations you'll always have enough space to = avoid a DoS scenario. >=20 > Because potentially this would cause hundreds or thousands of NS = multicast packets on the LAN per second in a ddos scenario? >=20 > If we can avoid the router having to learn anything by means of = external packet triggers, I think it would be a big win. a game of whac-a-mole? ;-) at least you have a new set of problems that needs to be solved. - how is state maintained on the first-hop router(s)? how does the host detect that the first-hop router has lost state? how do you synchronize state between the set of routers on the link? - while ND classic scales by the number of active addresses on the link, you'll now scale by the total number of addresses on the link - how do routers garbage collect? i.e. how do routers detect that an = address is no longer in use,=20 the node has left the link? as Lorenzo stated I believe the external DOS attacks on the ND cache can = be mostly mitigated by a good implementation. prioritising the active speakers, = rate-limiting the number of request per second, use a circular buffer and so on. it wouldn't be completely unexpected if = there was some level of stateful or stateless filtering being done on the borders stopping these = forms of attacks either. that said, vendors do implement snooping solutions e.g.=20 = http://www.cisco.com/en/US/docs/ios-xml/ios/ipv6_fhsec/configuration/xe-3s= /ip6f-xe-3s-book.pdf (not touting cisco's solution here, I'm sure all the other vendors have = similar, but it was the first I found).=20 that use ND and DHCP snooping to maintain a stateful table on the = first-hop routers and switches. address registration may make such solutions easier to implement. cheers, Ole --Apple-Mail=_94E8FEDD-DE7E-42FA-9044-CB664383ECB3 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 iQEcBAEBCgAGBQJSzm4JAAoJEFuJXizso86gWZsH/0SEUp68zsDXYlGZr5YrJHxd wde7tXxbJ8S9RIoJdmwJavsR27IdwBrHwCfnpYIIuInCbXt1QaiRTgSpM7NCKzme 4H2N+s4PX2R/FBQI3YdKjOIX2eJaAq2KuLAo9G3mFt2dTbwkR7pVIrVrkyPRWdxO 30i+LSefLFNMN3rVfv2YSAvFvKhTpBs9O4UQGMHxI046QqaC1gXuCiVpiOsVhGpy xG7J53jCzCzgy5pN/aalDKbu15QGqjOkCdWhYAALSv7l0ZvSOu5x3x7gcAGmUP78 Cw13LEc/Y+k/spsWHWtH8jEIfnqINdXDB+xebY4sdPt+5LI5KebHnEGbC8FXPIc= =rk8F -----END PGP SIGNATURE----- --Apple-Mail=_94E8FEDD-DE7E-42FA-9044-CB664383ECB3-- From lorenzo@google.com Thu Jan 9 01:58: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 947571AE201 for ; Thu, 9 Jan 2014 01:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, 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 0yBef9LYfW-b for ; Thu, 9 Jan 2014 01:58:26 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 23E661AE1FF for ; Thu, 9 Jan 2014 01:58:26 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id x13so3205533ief.24 for ; Thu, 09 Jan 2014 01:58:16 -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=XUfHW40wi/spZhGYLY593kA6uYLgmm2uIoIOn2hOSLw=; b=aqD9diiRxOucBbqGgaOjFKG/NSCodkb3mfOf+Sk4Pq3wk7HjKAH53g/YqX8JuRwaYt j6G8nKHUgT39mIRNBMTBmO94B2uT52YfAbbC21crOOUBuh5xzkuPe1/P1urlwT6wyLI5 V4i9FNxOJ4wmLAmBpUnJrwhgsispxt7h5zjWypsVRz78fVhxlSdnGO2rPoNnIxWKvN/m 8U7eAJzuKINWYbLJpHVU8T6JIGKnTlFFLywwQhDTkfSLg/bnrkM7Zfcaoi4DZ+7hRqEK adswQLo7qjUfm7+Z3uwWHZ1mGoU0XbklOVsg6a9qfb0NoNImI18FpQZzYJ/zA2lIrpNA n2Yg== 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=XUfHW40wi/spZhGYLY593kA6uYLgmm2uIoIOn2hOSLw=; b=Mbln3SRuJC1E5GseE6R7H5l/fRBGBooSxXHZVsBcIbzsSjwbzW+uxXp/l6jFcBVR5X SYmyvc3diMd3QD3lMNxYnJkvZ7oV/n7L8whI7GFk47cJFmzuTl528L3OUW7eT8Rhxhh1 PrSZ/ExvS+bnLH8IQH6IbLG9yhKFnBIVoQF0pNHJrHDApfjEaMdWlvUqk53LTDK26tzo TVR0I1lKnX76cKo8HoKln3vbQn2TGXYQv596+bKlfpiJl9xD4nTzF2e8X4QQFAfpssH4 p1L5o+j/xjVspIQK3lTyECODIm+DTOJTZCRNGpZnmAaOvKfsP0moLRuktq8SPH21GTTr Ar7Q== X-Gm-Message-State: ALoCoQkgTxG0T4CYdTPDMiwJQR3NX54W1+DsDBSu+5bSSQhGFP1qkwYVrrLddko44ej/BUbViqjKUptMCjnuKacODEfcWR/aVZ/Pd4A12QZTi/BUzVkthgKwjpmv6uyrnrK29b48oCej9vkxlpvaHpPo7vKSv5QLD3aAkY9KMKjFpnw++LiKi2Dw0GVIHGyc0w7Ht+w+mqwO X-Received: by 10.50.61.137 with SMTP id p9mr37428555igr.45.1389261496646; Thu, 09 Jan 2014 01:58:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Thu, 9 Jan 2014 01:57:56 -0800 (PST) In-Reply-To: References: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> From: Lorenzo Colitti Date: Thu, 9 Jan 2014 18:57:56 +0900 Message-ID: Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=047d7bdca5dc0232f204ef86a64e Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 09 Jan 2014 09:58:27 -0000 --047d7bdca5dc0232f204ef86a64e Content-Type: text/plain; charset=UTF-8 On Thu, Jan 9, 2014 at 4:57 PM, Mikael Abrahamsson wrote: > > Why not? What's the downside of sending out an NS for an address that's >> not there? You consume an ND cache slot for the incomplete entry, but if >> you use the optimizations you'll always have enough space to avoid a DoS >> scenario. >> > > Because potentially this would cause hundreds or thousands of NS multicast > packets on the LAN per second in a ddos scenario? > They would be rate-limited, just like any other ND packets on any implementation worth its salt. I think an NS is 72 bytes including ICMPv6 header; if so, then even if you send out 500 of them per second, that's 36 kB/s. What sort of link has a problem carrying 36 kB/s? How many NSes per second can routers send out anyway? > If we can avoid the router having to learn anything by means of external > packet triggers, I think it would be a big win. Maybe in terms of bandwidth, but that's not free - you're trading off bandwidth with state. The state has to be maintained, recovered on reboot, synchronized between multiple routers, etc. etc., and that is brittle. --047d7bdca5dc0232f204ef86a64e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 9, 2014 at 4:57 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:

Why not? What's the downside of sending out an NS for an address that&#= 39;s not there? You consume an ND cache slot for the incomplete entry, but = if you use the optimizations you'll always have enough space to avoid a= DoS scenario.

Because potentially this would cause hundreds or thousands of NS multicast = packets on the LAN per second in a ddos scenario?

=
They would be rate-limited, just like any other ND packets on an= y implementation worth its salt. I think an NS is 72 bytes including ICMPv6= header; if so, then even if you send out 500 of them per second, that'= s 36 kB/s. What sort of link has a problem carrying 36 kB/s? How many NSes = per second can routers send out anyway?
=C2=A0
If we can avoid the router = having to learn anything by means of external packet triggers, I think it w= ould be a big win.

Maybe in terms of bandwidth, but that's not free - = you're trading off bandwidth with state. The state has to be maintained= , recovered on reboot, synchronized between multiple routers, etc. etc., an= d that is brittle.
--047d7bdca5dc0232f204ef86a64e-- From swmike@swm.pp.se Thu Jan 9 04:44: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 A49C61AE0F7 for ; Thu, 9 Jan 2014 04:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.389 X-Spam-Level: X-Spam-Status: No, score=-4.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 dQ7dvI2ykbJ7 for ; Thu, 9 Jan 2014 04:44:25 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 07E681AE247 for ; Thu, 9 Jan 2014 04:44:24 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7D3AF9C; Thu, 9 Jan 2014 13:44:14 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 758A69A; Thu, 9 Jan 2014 13:44:14 +0100 (CET) Date: Thu, 9 Jan 2014 13:44:14 +0100 (CET) From: Mikael Abrahamsson To: Lorenzo Colitti Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 In-Reply-To: Message-ID: References: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 09 Jan 2014 12:44:27 -0000 On Thu, 9 Jan 2014, Lorenzo Colitti wrote: > They would be rate-limited, just like any other ND packets on any > implementation worth its salt. I think an NS is 72 bytes including > ICMPv6 header; if so, then even if you send out 500 of them per second, > that's 36 kB/s. What sort of link has a problem carrying 36 kB/s? How > many NSes per second can routers send out anyway? I don't know, people seem to indicate that there is a problem with multicast pps on wifi links. I haven't seen any hard data on this, it was just my interpretation that this was considered a problem. > Maybe in terms of bandwidth, but that's not free - you're trading off > bandwidth with state. The state has to be maintained, recovered on > reboot, synchronized between multiple routers, etc. etc., and that is > brittle. Yes, I agree. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Thu Jan 9 04:45: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 3DFE61AE25C for ; Thu, 9 Jan 2014 04:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.538, 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 QrgPnrg9Kd0g for ; Thu, 9 Jan 2014 04:45:48 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id BDA691AE260 for ; Thu, 9 Jan 2014 04:45:48 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id F3D459C; Thu, 9 Jan 2014 13:45:38 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id ED4A99A; Thu, 9 Jan 2014 13:45:38 +0100 (CET) Date: Thu, 9 Jan 2014 13:45:38 +0100 (CET) From: Mikael Abrahamsson To: Ole Troan Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 In-Reply-To: <27F0E5E5-50C1-4B92-AA4F-A849BA10FC9C@employees.org> Message-ID: References: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> <27F0E5E5-50C1-4B92-AA4F-A849BA10FC9C@employees.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 09 Jan 2014 12:45:50 -0000 On Thu, 9 Jan 2014, Ole Troan wrote: > a game of whac-a-mole? ;-) > at least you have a new set of problems that needs to be solved. Absolutely. My first thinking was to understand if this could be done with minimal changes to the clients. > as Lorenzo stated I believe the external DOS attacks on the ND cache can > be mostly mitigated by a good implementation. prioritising the active > speakers, rate-limiting the number of request per second, use a circular > buffer and so on. it wouldn't be completely unexpected if there was some > level of stateful or stateless filtering being done on the borders > stopping these forms of attacks either. Well, that's a different game of whack-a-mole that needs flow state to be kept in order to find attacks. -- Mikael Abrahamsson email: swmike@swm.pp.se From lorenzo@google.com Thu Jan 9 05:34: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 D0E991AE2CD for ; Thu, 9 Jan 2014 05:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, 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 FZ_G1UG6NFZs for ; Thu, 9 Jan 2014 05:34:09 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 641791AE2CB for ; Thu, 9 Jan 2014 05:34:07 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id hk11so16062409igb.1 for ; Thu, 09 Jan 2014 05:33:57 -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=u7rDPhRJl5bU+OPAQ/FWn/C5Znhc/etrIHf5ueFWIJ0=; b=a36CRBysJ26ziiEriy+cokY6J3xtv1fsj0xmw9y9t/FtSKu+uaRg8RlB3I5WfPlVxd Kpwv5swUot+4appSOxaPq/8SAzXB5egT+tEuDeHC1Z9bLe8N0npwwMi+u/E7HV3Suy3e FLUE5k4e4kn3Iy3fwcv/OLV0Tfc5aJqRJmIq1TgT8nCQOVPKQSPjGCrqrd4F7mvptZ6K zqR2jY3cedEbLWuFeBRbTqWMOA9ci0BcSdRCH5jEG+Av/u2KIc9tCv+SrhUv7jAMslSH f/+/QEf/rXdBT8Vzfgpp5EzgdYYuK2cALdebTUXEbkY+hLohqxPZOzF2kCgL1+zRfhPO buHg== 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=u7rDPhRJl5bU+OPAQ/FWn/C5Znhc/etrIHf5ueFWIJ0=; b=gFblcDbieVBV7SkWnaIcJ9FG8A6ISLx/I3UEPYQrNqlDj0b7vu0yUxT+LAQGT4SGi2 Gatli7w16bjgYMt2wbtZwSMGgYMTVylM6oQgPwcy3fzaJbzB+WO7QC2mzxqFo5nKZCzC tcmUrLwzYXaDuYzrJvCTntKK5uooQ+oWI2/YDSCUE9oOGonBngTFXtQPC8x3gwibS11d aO5HrKtJFrMfgQ5Lcs1NhmAHMxnKOSgdighbKqn6PuU0e/AVO/5C4ZAAGsIHT5oZm3BY ny/OvQuJcnXEET6Y/qPMDGz7THMezUIUQ5p15XdCCO4RnLIutI3dJB4OAUhbIlswgE7L A6Mw== X-Gm-Message-State: ALoCoQkFrNAa0D2t11nQqjHBBvD+Qga0735PMj8q24bZY9uKXEeATRW+GSsvvCxauoFWqlCF6lyAEcZK8mdmJZ20mdYGp7Vnc7ZUC4+TAvhI7J3ZG6JPGz8pVfgQV5T2vwFdUq+ZOoRT8+IF+85iYHPXoVt4GIAgYEphJ7gKU93lDElbkc6Bygt3++1XXRsMqHmnKJ6e5th9 X-Received: by 10.50.61.101 with SMTP id o5mr3248967igr.31.1389274437686; Thu, 09 Jan 2014 05:33:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Thu, 9 Jan 2014 05:33:37 -0800 (PST) In-Reply-To: References: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> From: Lorenzo Colitti Date: Thu, 9 Jan 2014 22:33:37 +0900 Message-ID: Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=001a113603505ad6c404ef89a98c Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 09 Jan 2014 13:34:11 -0000 --001a113603505ad6c404ef89a98c Content-Type: text/plain; charset=UTF-8 On Thu, Jan 9, 2014 at 9:44 PM, Mikael Abrahamsson wrote: > >> They would be rate-limited, just like any other ND packets on any >> implementation worth its salt. I think an NS is 72 bytes including ICMPv6 >> header; if so, then even if you send out 500 of them per second, that's 36 >> kB/s. What sort of link has a problem carrying 36 kB/s? How many NSes per >> second can routers send out anyway? >> > > I don't know, people seem to indicate that there is a problem with > multicast pps on wifi links. I haven't seen any hard data on this, it was > just my interpretation that this was considered a problem. Knowing nothing about this, I will cite http://stackoverflow.com/a/4341485, hoping that the draft authors will come along with more detailed data (which hopefully they have already presented to justify their use case and which I missed): === With unicast the access point tracks what data rate every particular receiver can reliably receive at, and sends about that rate. With multicast the access point does not know which receivers are interested in the data, so simple access points send the data at the slowest possible rate (1Mb/s). Better implemented access points may send the data at the rate that the slowest connected client is using, and the best access points use IGMP snooping to see who's receiving each IP multicast stream, and they will choose the slowest rate out of the receivers for that stream. === Even 1Mbps is still a fair number of ND packets though. --001a113603505ad6c404ef89a98c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 9, 2014 at 9:44 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:

They would be rate-limited, just like any other ND packets on any imple= mentation worth its salt. I think an NS is 72 bytes including ICMPv6 header= ; if so, then even if you send out 500 of them per second, that's 36 kB= /s. What sort of link has a problem carrying 36 kB/s? How many NSes per sec= ond can routers send out anyway?

I don't know, people seem to indicate that there is a problem with mult= icast pps on wifi links. I haven't seen any hard data on this, it was j= ust my interpretation that this was considered a problem.

Knowing nothing about this, I will cite http://stackoverflow.com/a/4341485 , ho= ping that the draft authors will come along with more detailed data (which = hopefully they have already presented to justify their use case and which I= missed):

=3D=3D=3D
With unicast the access point track= s what data rate every particular receiver can reliably receive at, and sen= ds about that rate. With multicast the access point does not know which rec= eivers are interested in the data, so simple access points send the data at= the slowest possible rate (1Mb/s). Better implemented access points may se= nd the data at the rate that the slowest connected client is using, and the= best access points use IGMP snooping to see who's receiving each IP mu= lticast stream, and they will choose the slowest rate out of the receivers = for that stream.
=3D=3D=3D

Even 1Mbps is still a fair number o= f ND packets though.
--001a113603505ad6c404ef89a98c-- From lorenzo@google.com Thu Jan 9 06:22: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 2B38D1AE339 for ; Thu, 9 Jan 2014 06:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, 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 pbp4nnNnNJiq for ; Thu, 9 Jan 2014 06:22:26 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4A81AE32D for ; Thu, 9 Jan 2014 06:22:26 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id k19so7650936igc.2 for ; Thu, 09 Jan 2014 06:22:16 -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=gahPPRL+l1WRiqQCT38VsIxxR2YhNj7Q4jb8DQhZsx8=; b=Gb0acgbbj5K5/Cn2XY7+0LDeifFuiUzGjWXFRR9r0sByCY3o2F2/k+ixyf5TtV+KhB I94ZSzOoSGQBhKLJS2+CdvdBokfRQaApYH8yAhhJ+LaTUHy4e+hhxvlYs2+nFEskJKF4 Zx2XjffiAb9p7NidXq+LZmQ9FsYa2rOymZTOeZIKvXgiwolDyD+kI7fgU1sPwLPYRb/0 xy7yXOpOIi9N0GsSrAb5kwniCDE+J2Ioy2JKlomr60cE8cky/9+INJJRMoLZvsuA66X4 XH23FJBRDARjJmvE1xCvlTuYgoQyPSayR2WUCt5xXyVFl29YgrS4NSqQsi7xGUhU9oPx GNww== 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=gahPPRL+l1WRiqQCT38VsIxxR2YhNj7Q4jb8DQhZsx8=; b=RS1Y1NgknhTfZYkx8HwKKzLwPeL5loPSpQ5gN03/5biYSCdoVMpuzIDeM9qxxpq3aH t3hWkY74JXtQKpjgQ2i1D0H8F9rWecmKufVORuApfjY0JY1QhieYnSkw5FgLwB4euOaJ pTM86oho7ws/4FTkbNcaDaCdvC+0IYU+1JNHj4WLf1THxXBWj9HeIF+0k5FLJl2Qesxe Bdx86kcanR2eVW8G2yD1jou2r8tOIG4hW/W/aMIj9SQ9qGqwo6Y0VCxLYqP/Z/O/ecXf qt4N7qC9SwqbYdhT2dqBEG+/S/zaPvGLVmXaVsU5SPTbuVQ7637do82AjWXHmItO8p4Q B2Xg== X-Gm-Message-State: ALoCoQmIy3iuDglctoMaZsVx96n3edJWnUqKRo2FfEYSWg95J4qRDulGpglfRc4Z2FWui5WRLyYyl6MiGGqk5OqST7HzVXBJ/vMYpoE0s1MHI+W5Hy1zIgTp3g3KYSiq5ZRUuxqflkBNCpcTqgC190mEFyMBJeVzRSPgZ6PxnxnoW6UiECwtFWfForj1yejeu8y0LSkwAYaH X-Received: by 10.50.79.228 with SMTP id m4mr37722923igx.47.1389277336445; Thu, 09 Jan 2014 06:22:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Thu, 9 Jan 2014 06:21:55 -0800 (PST) In-Reply-To: References: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> From: Lorenzo Colitti Date: Thu, 9 Jan 2014 23:21:55 +0900 Message-ID: Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=089e013a1f1622487a04ef8a561d Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 09 Jan 2014 14:22:29 -0000 --089e013a1f1622487a04ef8a561d Content-Type: text/plain; charset=UTF-8 On Thu, Jan 9, 2014 at 10:33 PM, Lorenzo Colitti wrote: > Knowing nothing about this, I will cite http://stackoverflow.com/a/4341485, hoping that the draft authors will come along with more detailed data > (which hopefully they have already presented to justify their use case and > which I missed): > Ok, so in VERY unscientific testing, tcpdump says that in 1 second, my phone was able to receive 2500-3000 72-byte IPv6 multicast packets sent by my laptop. This is on a 5GHz network using a standard home router access point (D-Link DIR-835). That doesn't seem all that slow. --089e013a1f1622487a04ef8a561d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 9, 2014 at 10:33 PM, Lorenzo Colitti <lorenzo@google.com>= wrote:
Knowing nothing about= this, I will cite http://stackoverflow.com/a/4341485 , hoping that the draft authors will come along with more d= etailed data (which hopefully they have already presented to justify their = use case and which I missed):

Ok, so in VERY unscienti= fic testing, tcpdump says that in 1 second, my phone was able to receive 25= 00-3000 72-byte IPv6 multicast packets sent by my laptop. This is on a 5GHz= network using a standard home router access point (D-Link DIR-835). That d= oesn't seem all that slow.
--089e013a1f1622487a04ef8a561d-- From he@uninett.no Thu Jan 9 07:29: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 13A8B1ADE84 for ; Thu, 9 Jan 2014 07:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 vshGwUnbYTP4 for ; Thu, 9 Jan 2014 07:29:23 -0800 (PST) Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:ced]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0831AE3B1 for ; Thu, 9 Jan 2014 07:29:23 -0800 (PST) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 076A13D0B3; Thu, 9 Jan 2014 16:29:12 +0100 (CET) Date: Thu, 09 Jan 2014 16:29:11 +0100 (CET) Message-Id: <20140109.162911.09934417.he@uninett.no> To: lorenzo@google.com Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 From: Havard Eidnes In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man-chairs@tools.ietf.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, 09 Jan 2014 15:29:26 -0000 > On Thu, Jan 9, 2014 at 10:33 PM, Lorenzo Colitti = wrote: > >> Knowing nothing about this, I will cite http://stackoverflow.com/a/4= 341485, hoping that the draft authors will come along with more detaile= d data >> (which hopefully they have already presented to justify their use ca= se and >> which I missed): >> > > Ok, so in VERY unscientific testing, tcpdump says that in 1 second, m= y > phone was able to receive 2500-3000 72-byte IPv6 multicast packets se= nt by > my laptop. This is on a 5GHz network using a standard home router acc= ess > point (D-Link DIR-835). That doesn't seem all that slow. A couple of questions worth pondering: how much of the channel capacity is consumed by that traffic, and what was the limiting factor in your experiment. Regards, - H=E5vard From v6ops@globis.net Thu Jan 9 08:21: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 21C031AE432 for ; Thu, 9 Jan 2014 08:21:24 -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 4cRJqH5EBBoW for ; Thu, 9 Jan 2014 08:21:22 -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 85D6C1ADF55 for ; Thu, 9 Jan 2014 08:21:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id DBC878714A4; Thu, 9 Jan 2014 17:21:11 +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 Ph6diUuCyIxk; Thu, 9 Jan 2014 17:21:11 +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 B3EC48714A3; Thu, 9 Jan 2014 17:21:11 +0100 (CET) Message-ID: <52CECC76.1030706@globis.net> Date: Thu, 09 Jan 2014 17:21:10 +0100 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Lorenzo Colitti Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] References: <52C9D788.8060606@gmail.com> <52CBE0E6.5020107@globis.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 09 Jan 2014 16:21:24 -0000 > Lorenzo Colitti > 9 January 2014 03:27 > > It may not be a widely held belief, but I remain concerned about > the potential for resource exhaustion for any number of processes > due to the "massive over sizing" of prefixes to /64: any number of > untested processes that track state based on /128 IPv6 address > could be attacked. The flip side of expanding privacy through > address obfuscation at IID level is that the source space > available for attacks also increases. ND cache exhaustion is > probably just the first issue we've discovered of many that exist. > This may have knock on operational consequences, which in the IPv4 > world have relied on the scarcity of IPv4 address space to be able > to operate correctly under stress scenarios. We're going to > discover who has been swimming naked when the tide goes out. Call > that FUD, or operational expediency, whichever you like. BCP38 has > saved me on a number of occasions when all else has failed. > > > It's true that some implementations may have made incorrect > assumptions about IPv6 attacks based on their IPv4 knowledge. But on > the other hand, a /64 provides plentiful space, freedom from > renumbering, and operational simplicity because "you will always have > enough subnet space" and "you can pick your own IID because a /64 > provides enough space for everyone". > > I don't think it's a good trade-off to give up those advantages just > because of some implementations may temporarily have made insecure > choices. By the same token, we didn't design IPv4 to be partitioned > into security zones, even though I'm sure that when IPv4 rolled > around, people were shocked - and I'm sure some got burnt - by the > fact that enabling IPv4 on a machine suddenly meant that the machine > was suddenly accessible from anywhere in the world. I think it's much > better to start with a flexible, full-featured, simple architecture > and them secure it. > > It's not that securing it is hard to do: in first instance, make the > abuse systems just track /64s instead of tracking /128s, and problem > solved. Of course, you still have the problem that there are too many > /64s to keep track of, but there's no way around that except to stick > with IPv4, or make a new protocol that has more address space than > IPv4 but less address space than IPv6... but why would you want that? > > I know that smaller subnets are consistent with IPv4. But "different > from IPv4" doesn't mean "worse than IPv4". In many cases, it means > "better than IPv4". > > ------------------------------------------------------------------------ Most organisations I know have way less than 100K hosts globally, and typically 10's or 100s of hosts per LAN. We seem to agree that people can't track at /64 because 2^64 is too big to track. Why then would we suggest that people track at /64 level when you already admit there's equally too many /64's to track (also 2^64)? The point is that people *could* trivially track and filter at /128 within an enterprise *if* we give network infra people the ability to control/register which /128(s) the end host uses. Ideally, that ability to control/register active /128's should not rely on cooperation of L2 switches or other LAN functionality that requires purchasing new switches, or constant MIB scanning. I think that's a valid problem statement, and assigning >>/64 (purposefully breaking SLAAC, whilst deploying stateful DHCPv6, or static addressing) is one way to address that problem. Is there anything better? -- Regards, RayH From alexandru.petrescu@gmail.com Thu Jan 9 08:25: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 BA6591AE00D for ; Thu, 9 Jan 2014 08:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.983 X-Spam-Level: X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, 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 EQPudwIBrJNZ for ; Thu, 9 Jan 2014 08:25:33 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id BD9461ADEB5 for ; Thu, 9 Jan 2014 08:25:32 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s09GPMAD029433 for ; Thu, 9 Jan 2014 17:25:22 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E98A72069FC for ; Thu, 9 Jan 2014 17:26:23 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 347F12069E2 for ; Thu, 9 Jan 2014 17:26:21 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s09GPFE9003127 for ; Thu, 9 Jan 2014 17:25:19 +0100 Message-ID: <52CECD6B.2020408@gmail.com> Date: Thu, 09 Jan 2014 17:25:15 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] References: <52C9D788.8060606@gmail.com> <52CE105E.4050102@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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, 09 Jan 2014 16:25:34 -0000 Le 09/01/2014 04:19, Lorenzo Colitti a écrit : > On Thu, Jan 9, 2014 at 11:58 AM, Brian E Carpenter > > wrote: > > > "For all unicast addresses, except those that start with the > binary value > > 000, Interface IDs are required to be 64 bits long". > > Actually that (truncated) sentence is obsoleted by > draft-ietf-6man-ug which > is in the RFC queue. New version: > > "For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long. If > derived > > > ... which is exactly the sentence I cited, right? I did look at > draft-ietf-6man-ug before I blurted out, you know :-) Let me try a clarification. If it dares too far, excuses. RFC4291 Addr Arch document says prefixes are of length n and IIDs of length 128-n. Further it says that IIDs are required to be 64bit long. A new document now in RFC Editor queue says that IIDs must be 64bit long and, additionally, when derived from a 48bit MAC address they must be constructed as 'Modified EUI-64'. (this is part of the u/g discussion). This is not the end of the story, but could be a path to it. Let me say why. One agrees that addresses are n/128-n. Then one makes them 64. Then make them 64-but. And further one may try to interpret them as along these hypothetical lines: > "For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 128-n bits long. If derived > from an IEEE MAC-layer address, they must be constructed in Modified > EUI-64 format." This is just speculation on my part. Alex > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From tjc@ecs.soton.ac.uk Thu Jan 9 08:32:35 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 497821ADFB9 for ; Thu, 9 Jan 2014 08:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 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.538, SPF_NEUTRAL=0.779] 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 22Y-MT0djBww for ; Thu, 9 Jan 2014 08:32:33 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 26AA71ADFA7 for ; Thu, 9 Jan 2014 08:32:33 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s09GWEt2028212; Thu, 9 Jan 2014 16:32:14 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s09GWEt2028212 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1389285134; bh=Meq6sAIFbKkyyLlgXp1Ob7BGDww=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=1qhdP6LY1CZe+h0lTVisY1dyG/apc3LAdWi2+S42zkmNhHjwGXNfPqfvWcRoROnFk K6kBin608pmaIVPxEuIuwVo230KSuSQl3/lPkmak3vJ2dfL0v8sEeGbH5jBU88xtk5 9BTB4dnosa8y/j9b+g7TUVNxodLM9vua/Xq6pDHc= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q08GWE0959656019J8 ret-id none; Thu, 09 Jan 2014 16:32:14 +0000 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s09GWCUl030522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jan 2014 16:32:12 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] From: Tim Chown In-Reply-To: <52CECC76.1030706@globis.net> Date: Thu, 9 Jan 2014 16:32:16 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <52C9D788.8060606@gmail.com> <52CBE0E6.5020107@globis.net> <52CECC76.1030706@globis.net> <79D8AF81-2D90-4FF6-A513-4E4D89429E87@ecs.soton.ac.uk> To: Ray Hunter X-Mailer: Apple Mail (2.1510) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q08GWE095965601900; tid=q08GWE0959656019J8; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s09GWEt2028212 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk 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: Thu, 09 Jan 2014 16:32:35 -0000 On 9 Jan 2014, at 16:21, Ray Hunter wrote: >> Lorenzo Colitti >> 9 January 2014 03:27 >>=20 >> It may not be a widely held belief, but I remain concerned about >> the potential for resource exhaustion for any number of processes >> due to the "massive over sizing" of prefixes to /64: any number of >> untested processes that track state based on /128 IPv6 address >> could be attacked. The flip side of expanding privacy through >> address obfuscation at IID level is that the source space >> available for attacks also increases. ND cache exhaustion is >> probably just the first issue we've discovered of many that exist. >> This may have knock on operational consequences, which in the IPv4 >> world have relied on the scarcity of IPv4 address space to be able >> to operate correctly under stress scenarios. We're going to >> discover who has been swimming naked when the tide goes out. Call >> that FUD, or operational expediency, whichever you like. BCP38 has >> saved me on a number of occasions when all else has failed. >>=20 >>=20 >> It's true that some implementations may have made incorrect = assumptions about IPv6 attacks based on their IPv4 knowledge. But on the = other hand, a /64 provides plentiful space, freedom from renumbering, = and operational simplicity because "you will always have enough subnet = space" and "you can pick your own IID because a /64 provides enough = space for everyone". >>=20 >> I don't think it's a good trade-off to give up those advantages just = because of some implementations may temporarily have made insecure = choices. By the same token, we didn't design IPv4 to be partitioned into = security zones, even though I'm sure that when IPv4 rolled around, = people were shocked - and I'm sure some got burnt - by the fact that = enabling IPv4 on a machine suddenly meant that the machine was suddenly = accessible from anywhere in the world. I think it's much better to start = with a flexible, full-featured, simple architecture and them secure it. >>=20 >> It's not that securing it is hard to do: in first instance, make the = abuse systems just track /64s instead of tracking /128s, and problem = solved. Of course, you still have the problem that there are too many = /64s to keep track of, but there's no way around that except to stick = with IPv4, or make a new protocol that has more address space than IPv4 = but less address space than IPv6... but why would you want that? >>=20 >> I know that smaller subnets are consistent with IPv4. But "different = from IPv4" doesn't mean "worse than IPv4". In many cases, it means = "better than IPv4". >>=20 >> = ------------------------------------------------------------------------ > Most organisations I know have way less than 100K hosts globally, and = typically 10's or 100s of hosts per LAN. >=20 > We seem to agree that people can't track at /64 because 2^64 is too = big to track. >=20 > Why then would we suggest that people track at /64 level when you = already admit there's equally too many /64's to track (also 2^64)? >=20 > The point is that people *could* trivially track and filter at /128 = within an enterprise *if* we give network infra people the ability to = control/register which /128(s) the end host uses. >=20 > Ideally, that ability to control/register active /128's should not = rely on cooperation of L2 switches or other LAN functionality that = requires purchasing new switches, or constant MIB scanning. >=20 > I think that's a valid problem statement, and assigning >>/64 = (purposefully breaking SLAAC, whilst deploying stateful DHCPv6, or = static addressing) is one way to address that problem. I;m not sure you're defining what your problem is fully enough here. What's wrong with polling network devices to maintain a database of = IP/MAC/port bindings? Some reasonably sized campuses with IPv6 deployed = do just that, on the assumption devices can effectively pick their own = addresses and/or change them over time. Tim From v6ops@globis.net Thu Jan 9 09:18: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 D46BE1AE044 for ; Thu, 9 Jan 2014 09:18:45 -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 XpDxfiGb6tiG for ; Thu, 9 Jan 2014 09:18:44 -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 A16CB1AE4B0 for ; Thu, 9 Jan 2014 09:18:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id A5A758714A2; Thu, 9 Jan 2014 18:18:34 +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 cknqV4RzyUWP; Thu, 9 Jan 2014 18:18:34 +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 7FDCF870F98; Thu, 9 Jan 2014 18:18:34 +0100 (CET) Message-ID: <52CED9E9.5000702@globis.net> Date: Thu, 09 Jan 2014 18:18:33 +0100 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Tim Chown Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] References: <52C9D788.8060606@gmail.com> <52CBE0E6.5020107@globis.net> <52CECC76.1030706@globis.net> <79D8AF81-2D90-4FF6-A513-4E4D89429E87@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 09 Jan 2014 17:18:46 -0000 > Tim Chown > 9 January 2014 17:32 > > I;m not sure you're defining what your problem is fully enough here. > > What's wrong with polling network devices to maintain a database of > IP/MAC/port bindings? Some reasonably sized campuses with IPv6 > deployed do just that, on the assumption devices can effectively pick > their own addresses and/or change them over time. > > Tim I'd also probably consider that on a campus, which is geographically limited, there's no latency, network devices are uniform, there's a single management vendor, SNMP access is allowed, and bandwidth is free. DHCP (which is effectively a form of event-triggered central registration) works pretty well today. Two people can support all global IPAM, DHCP, and DNS for 100K users in 50 countries. All you need is the lowest common denominator of a DHCP proxy on any LAN equipment pointing at your regional servers, and a DHCP client on end user devices, which is basically universally supported. And you can lever that information up in all sorts of ways. DHCPv6 would not be cost impacting (part of licensing on existing kit). Anything else would be. You're not going to be able to get any less than 2 support people for this sort of enterprise critical infra. Off topic for this ID, but just saying. The bottom line is that sparse addressing in IPv6, as implemented today, also has a down side for enterprise operations; but perhaps that discussion should be held in v6ops. -- Regards, RayH From tjc@ecs.soton.ac.uk Thu Jan 9 09:31: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 1E2641AE3DC for ; Thu, 9 Jan 2014 09:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 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.538, SPF_NEUTRAL=0.779] 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 YFkV-wavVd6q for ; Thu, 9 Jan 2014 09:31:41 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 1475A1AE4D2 for ; Thu, 9 Jan 2014 09:31:36 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s09HVOoS015727; Thu, 9 Jan 2014 17:31:24 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s09HVOoS015727 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1389288685; bh=eh+S3gkLc46z7ziljfTkrkSlgeo=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=IB3ynBv3i5w+RS7iDYpKWm+KSIqyrYCRRMVRDznhabmKoHOc0CMxKBNqryhAWC2W6 6V7bE6oCe9AH3DHyQk6gDMUaM7ZugFnF0U7nM07G8lbg0WPDsclng5btkq9HsPgmLN 87PmGVCNje5+pELgO0nzN5wMFv6G9CY3uyn6wZzs= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q08HVO09596566744Y ret-id none; Thu, 09 Jan 2014 17:31:25 +0000 Received: from dhcp-163-17.wireless.soton.ac.uk (dhcp-163-17.wireless.soton.ac.uk [152.78.163.17] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s09HVMe3014303 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jan 2014 17:31:22 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] From: Tim Chown In-Reply-To: <52CED9E9.5000702@globis.net> Date: Thu, 9 Jan 2014 17:31:22 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <52C9D788.8060606@gmail.com> <52CBE0E6.5020107@globis.net> <52CECC76.1030706@globis.net> <79D8AF81-2D90-4FF6-A513-4E4D89429E87@ecs.soton.ac.uk> <52CED9E9.5000702@globis.net> <5CD4672C-43D5-4CB5-B371-E46AEDEB804C@ecs.soton.ac.uk> To: Ray Hunter X-Mailer: Apple Mail (2.1510) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q08HVO095965667400; tid=q08HVO09596566744Y; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s09HVOoS015727 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk 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: Thu, 09 Jan 2014 17:31:43 -0000 On 9 Jan 2014, at 17:18, Ray Hunter wrote: >> Tim Chown >> 9 January 2014 17:32 >>=20 >> I;m not sure you're defining what your problem is fully enough here. >>=20 >> What's wrong with polling network devices to maintain a database of = IP/MAC/port bindings? Some reasonably sized campuses with IPv6 deployed = do just that, on the assumption devices can effectively pick their own = addresses and/or change them over time. >>=20 >> Tim >=20 > I'd also probably consider that on a campus, which is geographically = limited, there's no latency, network devices are uniform, there's a = single management vendor, SNMP access is allowed, and bandwidth is free. >=20 > DHCP (which is effectively a form of event-triggered central = registration) works pretty well today. Two people can support all global = IPAM, DHCP, and DNS for 100K users in 50 countries. All you need is the = lowest common denominator of a DHCP proxy on any LAN equipment pointing = at your regional servers, and a DHCP client on end user devices, which = is basically universally supported. And you can lever that information = up in all sorts of ways. DHCPv6 would not be cost impacting (part of = licensing on existing kit). Anything else would be. You're not going to = be able to get any less than 2 support people for this sort of = enterprise critical infra. Off topic for this ID, but just saying. Fair comment, but for a campus style network, I'd argue for the polling = approach, and it works well (enough). There's a distinction though between controlling addresses and being = able to observe all addresses that are in use. > The bottom line is that sparse addressing in IPv6, as implemented = today, also has a down side for enterprise operations; but perhaps that = discussion should be held in v6ops. Well, I think it's relevant to this draft. I'm not sure it's really down to the sparse addressing per se, rather = that there is enough address space in a subnet for there to be a = mechanism for hosts to pick multiple addresses to use over time. Tim From ml@sekil.fr Thu Jan 9 09:51: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 C6FC71AE2B9 for ; Thu, 9 Jan 2014 09:51:32 -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 MMfwZsmBpGkw for ; Thu, 9 Jan 2014 09:51:30 -0800 (PST) Received: from host1.ip6-networks.net (host1.ip6-networks.net [IPv6:2a02:a80:0:2056::2]) by ietfa.amsl.com (Postfix) with ESMTP id 58FBC1ADF6D for ; Thu, 9 Jan 2014 09:51:30 -0800 (PST) Received: from [IPv6:2001:660:7301:3728:226:b0ff:fefa:237d] (unknown [IPv6:2001:660:7301:3728:226:b0ff:fefa:237d]) by host1.ip6-networks.net (Postfix) with ESMTPSA id A76BB60202; Thu, 9 Jan 2014 18:51:19 +0100 (CET) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Emmanuel Thierry In-Reply-To: <52C9D788.8060606@gmail.com> Date: Thu, 9 Jan 2014 18:51:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52C9D788.8060606@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1085) 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: Thu, 09 Jan 2014 17:51:32 -0000 Hello, (first message on these lists, hope it is accurate) I'm generally thinking that the /64 limit helps to structure the address = space from the receiver point of view. Let's say i'm running a mail = server which tries to reduce spam by temporarily blacklisting some = senders. if i'm facing spammers who use their IPv6 address space in a = smart way, they will just have to generate RFC 4941 addresses to exhaust = a firewall memory. The pragmatic way to face such attacks is to = blacklist the whole /64, never a unique /128. I don't know if it is to be considered as a best practice, but for these = reasons, as a receiver, i personally consider a /64 to be assigned to a = unique link, or at least a network managed by a unique network = administrator. Enforcing this limit in protocol standards strengthen = this assumption. This might be an additional argument for the "please = keep /64 for unique links". As a consequence, subdivide a /64 into several prefixes in order to = assign it on several networks might create a risk for devices on one = network to be blacklisted by actions performed by some devices on = another network, in case the whole /64 have been blacklist by a = "pragmatic" receiver.=20 Best regards Emmanuel Thierry Le 5 janv. 2014 =E0 23:07, Brian E Carpenter a =E9crit : > Hi, >=20 > A group of us put this together following a discussion some weeks > ago on the v6ops list about the 64-bit boundary in IPv6 addresses. > Discussion belongs in 6man, please. >=20 > This draft is incomplete but we'd welcome input. Let me underline > an important comment in the introduction: >=20 > _The purpose of this document is to analyse the issues around this > question. We make no proposal for change, but we do analyse the > possible effects of a change._ >=20 >=20 > Brian + co-authors >=20 > -------- Original Message -------- > Subject: I-D Action: draft-carpenter-6man-why64-00.txt > Date: Sun, 05 Jan 2014 13:59:17 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > 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-00.txt > Pages : 14 > Date : 2014-01-05 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-carpenter-6man-why64/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-carpenter-6man-why64-00 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From v6ops@globis.net Thu Jan 9 10:40: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 D1B861AE4F3 for ; Thu, 9 Jan 2014 10:40:09 -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 Wp6zw8bgSxDJ for ; Thu, 9 Jan 2014 10:40:08 -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 3845D1AE37A for ; Thu, 9 Jan 2014 10:40:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 3A7808714A3; Thu, 9 Jan 2014 19:39:58 +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 9v7XXMkWum5K; Thu, 9 Jan 2014 19:39:58 +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 18990870F98; Thu, 9 Jan 2014 19:39:58 +0100 (CET) Message-ID: <52CEECFE.8040701@globis.net> Date: Thu, 09 Jan 2014 19:39:58 +0100 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Tim Chown Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] References: <52C9D788.8060606@gmail.com> <52CBE0E6.5020107@globis.net> <52CECC76.1030706@globis.net> <79D8AF81-2D90-4FF6-A513-4E4D89429E87@ecs.soton.ac.uk> <52CED9E9.5000702@globis.net> <5CD4672C-43D5-4CB5-B371-E46AEDEB804C@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 09 Jan 2014 18:40:10 -0000 > Tim Chown > 9 January 2014 18:31 > On 9 Jan 2014, at 17:18, Ray Hunter wrote: > >>> Tim Chown >>> 9 January 2014 17:32 >>> >>> I;m not sure you're defining what your problem is fully enough here. >>> >>> What's wrong with polling network devices to maintain a database of IP/MAC/port bindings? Some reasonably sized campuses with IPv6 deployed do just that, on the assumption devices can effectively pick their own addresses and/or change them over time. >>> >>> Tim >> I'd also probably consider that on a campus, which is geographically limited, there's no latency, network devices are uniform, there's a single management vendor, SNMP access is allowed, and bandwidth is free. >> >> DHCP (which is effectively a form of event-triggered central registration) works pretty well today. Two people can support all global IPAM, DHCP, and DNS for 100K users in 50 countries. All you need is the lowest common denominator of a DHCP proxy on any LAN equipment pointing at your regional servers, and a DHCP client on end user devices, which is basically universally supported. And you can lever that information up in all sorts of ways. DHCPv6 would not be cost impacting (part of licensing on existing kit). Anything else would be. You're not going to be able to get any less than 2 support people for this sort of enterprise critical infra. Off topic for this ID, but just saying. > > Fair comment, but for a campus style network, I'd argue for the polling approach, and it works well (enough). > > There's a distinction though between controlling addresses and being able to observe all addresses that are in use. Agreed. Many scenarios I have in mind are about knowing all addresses in use, and who is using them. Not necessarily limiting them. >> The bottom line is that sparse addressing in IPv6, as implemented today, also has a down side for enterprise operations; but perhaps that discussion should be held in v6ops. > > Well, I think it's relevant to this draft. > > I'm not sure it's really down to the sparse addressing per se, rather that there is enough address space in a subnet for there to be a mechanism for hosts to pick multiple addresses to use over time. > > Tim > > My point of view is that there's a trade off to be made between "too few and too many" when talking about sparse address allocation, and that the current fixed /64 boundary allows "too many" IIDs/IPv6 addresses for many operational scenarios. So many in fact that it's a potential liability. Either that or we need a mechanism that more reliably tracks and registers addresses actually in use on a semi-trusted environment, so that the actual /128's in use are known (centrally) e.g. for improving/extending source address validation and anti-spoofing, helpdesk calls, log correlation, QoS tracking etc. As an example, how many implementations of QoS mechanisms like WFQ do you know today that protect their resources used for counting active flows on a /48 and /64 boundary? And how many just track session use per /128? Or have no limit at all on allowable active sessions per address/prefix? So how many implementations are vulnerable today to flow table size exhaustion that could have a global service impact by an attack from a single compromised host that can spoof source addresses from an entire /64 or /48? -- Regards, RayH From sander@steffann.nl Thu Jan 9 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 C3C4D1A1F5E for ; Thu, 9 Jan 2014 13:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 ybW4drp2H5_z for ; Thu, 9 Jan 2014 13:48:36 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) by ietfa.amsl.com (Postfix) with ESMTP id 757E81A1F06 for ; Thu, 9 Jan 2014 13:48:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 8D20353; Thu, 9 Jan 2014 22:48:25 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmJAXoWAC3D5; Thu, 9 Jan 2014 22:48:23 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTPSA id D723351; Thu, 9 Jan 2014 22:48:22 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 From: Sander Steffann In-Reply-To: Date: Thu, 9 Jan 2014 22:48:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0D19594A-F434-44C8-B02D-67B6FD401A9E@steffann.nl> References: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> To: Lorenzo Colittf X-Mailer: Apple Mail (2.1827) Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 09 Jan 2014 21:48:38 -0000 Hi, Op 9 jan. 2014, om 14:33 heeft Lorenzo Colitti het = volgende geschreven: > On Thu, Jan 9, 2014 at 9:44 PM, Mikael Abrahamsson = wrote: >=20 > They would be rate-limited, just like any other ND packets on any = implementation worth its salt. I think an NS is 72 bytes including = ICMPv6 header; if so, then even if you send out 500 of them per second, = that's 36 kB/s. What sort of link has a problem carrying 36 kB/s? How = many NSes per second can routers send out anyway? >=20 > I don't know, people seem to indicate that there is a problem with = multicast pps on wifi links. I haven't seen any hard data on this, it = was just my interpretation that this was considered a problem. >=20 > Knowing nothing about this, I will cite = http://stackoverflow.com/a/4341485 , hoping that the draft authors will = come along with more detailed data (which hopefully they have already = presented to justify their use case and which I missed): >=20 > =3D=3D=3D > With unicast the access point tracks what data rate every particular = receiver can reliably receive at, and sends about that rate. With = multicast the access point does not know which receivers are interested = in the data, so simple access points send the data at the slowest = possible rate (1Mb/s). Better implemented access points may send the = data at the rate that the slowest connected client is using, and the = best access points use IGMP snooping to see who's receiving each IP = multicast stream, and they will choose the slowest rate out of the = receivers for that stream. > =3D=3D=3D >=20 > Even 1Mbps is still a fair number of ND packets though. I think the issue is that, while 1Mbps is enough for ND, it is lowering = the speed for the whole channel. So in the time that the 72 byte packet = is sent at 1Mbps there *could* have been 3888 bytes at 54Mbps. And I = have no idea if the speed switch itself takes up any time. I know that Andrew Yourtchenko has some real life experience with this = stuff, so I'll put him in CC in case he has something to add. Cheers, Sander From lorenzo@google.com Thu Jan 9 21:02: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 5EB1A1ADF94 for ; Thu, 9 Jan 2014 21:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, 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 vJ17nwa-etqY for ; Thu, 9 Jan 2014 21:02:02 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id AF7581ADF4F for ; Thu, 9 Jan 2014 21:02:02 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id j1so18137762iga.2 for ; Thu, 09 Jan 2014 21:01:52 -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=D0mD1PhzjmcaooBsx7djRrVt2V4kGtiJ4s2cOaZOEfs=; b=HhzuZBrApSZR3qWs1RXSgfFF0i233TTkBAUwiq6RV6Qt9ygHdZYDol8iIRapVQxvH4 t0MqSQ9b8sO9nF5X4YrzUuqAUEPKosavKHoET0uIFEsYXcjyim/qHjtx/VxhZLfNxgsF SGa3h5uiIIbe2LUvhv3T+7Px62uhwuDeEBwTlRU68UaSKPW802hIT5Ak/uiZ7S8SncQL e+z4SC4VQRA0PwZM27z0FyPELNbBCVgk7l4yCFdtkwh81SoDCcFfJiFVDgTj2i7ZWZg8 /Ud13J5Y6CAH4cgXzM2YoFHxUi/+DNJXKQ1u4CeE89CUSAi2pbA52x6xGcVWLcl40eIM YLjQ== 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=D0mD1PhzjmcaooBsx7djRrVt2V4kGtiJ4s2cOaZOEfs=; b=heZc2xtUqetASv/Z9JaRll6pgSVQ47rxmWrQoodheDkhUt8/PZEArSJCnPHnN9HXIF rs2cjFiDCzGAltGoRoVtQ041qac9YUcOcQTKZUnvXFi9+1dLvgZP7U+fFP4pUelEQ4RQ I8wDuqf5Sf/KCBYlBfY4nmNdLwsVE6H2BH+OZiW6exp14dAfKyzPMK94PZsm+pPf0ylg vTaZX33z3FCEnqQeGtmg6XGu2NjB5u//MCfNjh3eXd7WFzeyxPiva02VID5CQfrZRx3n TPRkNbLoRjKoTpVNJNxeaq0FbQmoAfTj/Stfb/v1JwEwnTpYIe9FRtK2EgJDe3lWdWZm RYXw== X-Gm-Message-State: ALoCoQl6+VDWB6TafB9sQPSeBLxAiBvJVWAI70/t1zaRCq8TzoWTr3TKJZenl9axiVlK/uXGUmKzq74ZSZYHUND9FGvh5dieg1ZRZt6X5Zt6EhC8KHyRFNkHc1TARo9wgSrGoYmowwTRq0c0WGNSm6keK7eJ5AU8x/AZh/lEqIKtZfCd9CE09d/RRtSeYhSbrKnl08hWuI6i X-Received: by 10.50.238.162 with SMTP id vl2mr845925igc.45.1389330112752; Thu, 09 Jan 2014 21:01:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Thu, 9 Jan 2014 21:01:32 -0800 (PST) In-Reply-To: <52CECC76.1030706@globis.net> References: <52C9D788.8060606@gmail.com> <52CBE0E6.5020107@globis.net> <52CECC76.1030706@globis.net> From: Lorenzo Colitti Date: Fri, 10 Jan 2014 14:01:32 +0900 Message-ID: Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] To: Ray Hunter Content-Type: multipart/alternative; boundary=001a11335cfcd941a004ef969f06 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: Fri, 10 Jan 2014 05:02:04 -0000 --001a11335cfcd941a004ef969f06 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 10, 2014 at 1:21 AM, Ray Hunter wrote: > The point is that people *could* trivially track and filter at /128 within >> an enterprise *if* we give network infra people the ability to >> control/register which /128(s) the end host uses. >> > > Ideally, that ability to control/register active /128's should not rely on > cooperation of L2 switches or other LAN functionality that requires > purchasing new switches, or constant MIB scanning. > > I think that's a valid problem statement, and assigning >>/64 > (purposefully breaking SLAAC, whilst deploying stateful DHCPv6, or static > addressing) is one way to address that problem. > In your network you are free to assign addresses exclusively using DHCPv6. *However* - if you are doing this for the purpose of tracking, that only makes any sense at all if the current switches you have (since you've already said you're not going to buy new ones) can snoop DHCPv6 requests for address assignments enforce IPv6-to-MAC address mappings. Do they? Because if they don't, disabling SLAAC gives you no security at all, because malicious hosts on your network will still be free to create and use arbitrary IPv6 addresses, which you will not be able to track. In fact, this gives you the same level of security as you could by disabling privacy addresses and using autoconf - malicious hosts can still do what they want, and for well-behaved hosts, instead of having the MAC address in the IPv6 address, you now have to go and get it from the DHCPv6 server logs. Lose/lose. Or - as Tim points out, SNMP scraping will do this securely for you today, and vendors are already building better and more scalable address registration notification features (syslog, etc.) into switches. And if you're not doing this for the purpose of tracking, then why are you doing it? Is it just because it's what you do in IPv4? If so, then sorry, that's not a valid technical argument. --001a11335cfcd941a004ef969f06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 10, 2014 at 1:21 AM, Ray Hunter <v6ops@globis.net> wr= ote:
The point is that people *could* trivially track and filte= r at /128 within an enterprise *if* we give network infra people the abilit= y to control/register which /128(s) the end host uses.

Ideally, that ability to control/register active /128's should not rely= on cooperation of L2 switches or other LAN functionality that requires pur= chasing new switches, or constant MIB scanning.

I think that's a valid problem statement, and assigning >>/64 (pu= rposefully breaking SLAAC, whilst deploying stateful DHCPv6, or static addr= essing) is one way to address that problem.

In your network you are free to assign addresses exclusively using DHC= Pv6.

*However* - if you are doing this for the pur= pose of tracking, that only makes any sense at all if the current switches = you have (since you've already said you're not going to buy new one= s) can snoop DHCPv6 requests for address assignments enforce IPv6-to-MAC ad= dress mappings.

Do they?

Because if they don&#= 39;t, disabling SLAAC gives you no security at all, because malicious hosts= on your network will still be free to create and use arbitrary IPv6 addres= ses, which you will not be able to track. In fact, this gives you the same = level of security as you could by disabling privacy addresses and using aut= oconf - malicious hosts can still do what they want, and for well-behaved h= osts, instead of having the MAC address in the IPv6 address, you now have t= o go and get it from the DHCPv6 server logs. Lose/lose.

Or - as Tim points out, SNMP scraping will do this secu= rely for you today, and vendors are already building better and more scalab= le address registration notification features (syslog, etc.) into switches.=

And if you're not doing this for the pur= pose of tracking, then why are you doing it? Is it just because it's wh= at you do in IPv4? If so, then sorry, that's not a valid technical argu= ment.
--001a11335cfcd941a004ef969f06-- From v6ops@globis.net Fri Jan 10 00:11: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 BD6431ADF34 for ; Fri, 10 Jan 2014 00:11: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 leYbX9L0arVI for ; Fri, 10 Jan 2014 00:11:09 -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 D0DE91ADF28 for ; Fri, 10 Jan 2014 00:11:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 74B7D8714A2; Fri, 10 Jan 2014 09:10:58 +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 rSNRRJKbwCdD; Fri, 10 Jan 2014 09:10:58 +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 4F810870089; Fri, 10 Jan 2014 09:10:58 +0100 (CET) Message-ID: <52CFAB11.4070404@globis.net> Date: Fri, 10 Jan 2014 09:10:57 +0100 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Lorenzo Colitti Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] References: <52C9D788.8060606@gmail.com> <52CBE0E6.5020107@globis.net> <52CECC76.1030706@globis.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 10 Jan 2014 08:11:11 -0000 > Lorenzo Colitti > 10 January 2014 06:01 > > > Ideally, that ability to control/register active /128's should not > rely on cooperation of L2 switches or other LAN functionality that > requires purchasing new switches, or constant MIB scanning. > > I think that's a valid problem statement, and assigning >>/64 > (purposefully breaking SLAAC, whilst deploying stateful DHCPv6, or > static addressing) is one way to address that problem. > > > In your network you are free to assign addresses exclusively using DHCPv6. > > *However* - if you are doing this for the purpose of tracking, that > only makes any sense at all if the current switches you have (since > you've already said you're not going to buy new ones) can snoop DHCPv6 > requests for address assignments enforce IPv6-to-MAC address mappings. > > Do they? > You are apparently imposing a model which assumes a single management vendor is responsible right up until the edge of the network at port level. That is rarely true in any enterprise I've worked on. They are not my customer's switches. They don't manage them at all. They subcontract that to multiple parties. In the case of multiple management providers, people need to protect their own services from the failings of others. If a site is under autonomous management (e.g. trusted 3rd party) then they may be assigned a /48 in your model. OK they're responsible for their own /48 and they can suffer the consequences of poor management of devices in their site. But problems in their /48 with a rogue node assigning zillions of addresses and creating zillions of sessions should not spill over into the rest of the network managed by others. WFQ QoS (and many other processes which requires tracking of individual sessions or IP addresses) running in another vendor's network should not fail because of a single node in a single 3rd party network swamps an address/session table. I think that people need some way of limiting the number of active /128's at the network-network interface. It would be even better if we could either register or control to the /128 and identify those to a host or user. One way of doing that is to agree with trusted 3rd party sites (which generally only have a tiny number of hosts allowed to communicate across the boundary) to only assign an agreed /120 out of their /48 allocation, which requires prefix lengths >>64 (this ID) or at least the ability to apply ACL filters >> /64. Another way is source address validation at the edge, with limits assigned on a first come first served basis. Another is to ban all processes that need to track an individual IPv6 address. Another is to contract that the site themselves are responsible for limiting resource depletion attacks, but I'd still want some protection on the receiving side. I'd rather be tracking the 100K nodes that I know should be on the network out of a potential 24*2^16 addresses, rather than trying to stop a 100 zillion anonymous nodes who I can't even identify so that the 100K can work. DHCP has been successfully implemented in multi-vendor environments. The local LAN manager/outsourcer only has to configure up the LAN interface either the correct IP address and subnet mask, and point a DHCP proxy at a regional server (managed by someone else) They can make changes within a site autonomously without bothering the central team, and it all just works. DHCPv6 potentially can provide a form of centralised registration (and then be linked to admission control, or at least give cooperating end nodes a higher QoS than unidentified end nodes) and support a similar operations model. You could also allocate a /64, configure a DHCPv6 address pool to assign addresses from a range >>64 and apply and ACL, or assign and allocate >>64 prefix length (which seems easier). Because if they don't, disabling SLAAC gives you no security at all, because malicious hosts on your network will still be free to create and use arbitrary IPv6 addresses, which you will not be able to track. In fact, this gives you the same level of security as you could by disabling privacy addresses and using autoconf - malicious hosts can still do what they want, and for well-behaved hosts, instead of having the MAC address in the IPv6 address, you now have to go and get it from the DHCPv6 server logs. Lose/lose. That is also a problem. The assumption seems to be that there has been of smart nodes and a dumb network that does not run any processes requiring differential services or that tracking of individual end hosts is universally bad. But I thought we'd established that we're not exclusively talking about forcing use of particular addresses for all machines, rather establishing which nodes are genuinely active, and attempting to establish centrally what machine they are being used by. > > Or - as Tim points out, SNMP scraping will do this securely for you > today, and vendors are already building better and more scalable > address registration notification features (syslog, etc.) into switches. Not everyone allows SNMP access from other management vendors in a multi vendor environment. Not everyone feeds syslog to other management vendors. Again, you are imposing an alien operations model. It imposes polling, It imposes inter-vendor cooperation and access to all remote devices via a management protocol. Every time a switch on any one of 1000 sites changes, you're going to have to update your central poller. A central registration model avoids that overhead. > And if you're not doing this for the purpose of tracking, then why are > you doing it? Is it just because it's what you do in IPv4? If so, then > sorry, that's not a valid technical argument. At the risk of repeeating myself: helpdesk call correlation, problem correlation, log correlation, ability to track to /128 (for future filtering or tracking or resource protection of processes and devices within the network that rely on databases or caches keyed by IP address) In IPv4, this protection happens automatically due to address scarcity, without doing anything else. IPv6 /64 breaks address scarcity. -- Regards, RayH From tjc@ecs.soton.ac.uk Fri Jan 10 00:38: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 8F93C1ADFBC for ; Fri, 10 Jan 2014 00:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 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.538, SPF_NEUTRAL=0.779] 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 4JWbTsRkG3e1 for ; Fri, 10 Jan 2014 00:38:17 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDDF1AD8DA for ; Fri, 10 Jan 2014 00:38:16 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s0A8c2c0029018; Fri, 10 Jan 2014 08:38:02 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s0A8c2c0029018 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1389343082; bh=vu5BJ+ltpmuACAoT6096EcLo6xg=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=GOTGdsqx0hBGSect/G2DIEolUAHxKXj7x5Sb1XruM6sqWcSY/ojC6PvPMiMyrNILZ NAbr5CbbMLzehw1kYAgA5LWkIkWmdiz2pKp6FBDtD69JbyMloQ5Uo58g8NYA3GdDx7 e6DU5N9vtvTqt/VerA5FOyfc0dM1/SJsrfZuDVkk= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id q098c20959661066yD ret-id none; Fri, 10 Jan 2014 08:38:02 +0000 Received: from [192.168.1.107] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s0A8bsTe029963 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Jan 2014 08:37:54 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] From: Tim Chown In-Reply-To: <52CFAB11.4070404@globis.net> Date: Fri, 10 Jan 2014 08:37:53 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <52C9D788.8060606@gmail.com> <52CBE0E6.5020107@globis.net> <52CECC76.1030706@globis.net> <52CFAB11.4070404@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1827) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q098c2095966106600; tid=q098c20959661066yD; client=relay,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s0A8c2c0029018 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk 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: Fri, 10 Jan 2014 08:38:19 -0000 On 10 Jan 2014, at 08:10, Ray Hunter wrote: >> Lorenzo Colitti >>=20 >> Or - as Tim points out, SNMP scraping will do this securely for you = today, and vendors are already building better and more scalable address = registration notification features (syslog, etc.) into switches. > Not everyone allows SNMP access from other management vendors in a = multi vendor environment. Not everyone feeds syslog to other management = vendors. > Again, you are imposing an alien operations model. It imposes polling, = It imposes inter-vendor cooperation and access to all remote devices via = a management protocol. Actually, no. It's a choice. We saw the choice of trying to lock down = all address assignment for IPv6, or instead to accept that any device = can pick any address and put measures in place to monitor/track which = addresses are used where (should we need to trace something back). We = chose the latter approach. If you want to take the lock-down path, = that's your choice. > Every time a switch on any one of 1000 sites changes, you're going to = have to update your central poller. A central registration model avoids = that overhead. Well, yes, but there would be some provisioning for that device and you = just need to make the polling configuration part of that. It's usually = as simple as an address to poll. In our case (as you guess :) most of = our equipment is one vendor. The SNMP polling approach has advantages too. There's a lot of very = useful information you glean from that, that can be very beneficial in = aspects of network management other than address accountability. We also make quite heavy use of 802.1X btw, but then many campuses do so = today thanks to eduroam. >> And if you're not doing this for the purpose of tracking, then why = are you doing it? Is it just because it's what you do in IPv4? If so, = then sorry, that's not a valid technical argument. > At the risk of repeeating myself: helpdesk call correlation, problem = correlation, log correlation, ability to track to /128 (for future = filtering or tracking or resource protection of processes and devices = within the network that rely on databases or caches keyed by IP address) >=20 > In IPv4, this protection happens automatically due to address = scarcity, without doing anything else. >=20 > IPv6 /64 breaks address scarcity. I think many sites will see there are also positive sides to this, and = embrace it rather than trying to lock everything down. But it's a = choice. Tim= From alexandru.petrescu@gmail.com Fri Jan 10 00:54: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 976A91ACCEC for ; Fri, 10 Jan 2014 00:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, 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 v4GVGq6vWTTJ for ; Fri, 10 Jan 2014 00:54:06 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 0150A1A9313 for ; Fri, 10 Jan 2014 00:54:05 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s0A8rtZj026079 for ; Fri, 10 Jan 2014 09:53:55 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CA61020324C for ; Fri, 10 Jan 2014 09:54:57 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C0C70202091 for ; Fri, 10 Jan 2014 09:54:57 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0A8rocn005415 for ; Fri, 10 Jan 2014 09:53:55 +0100 Message-ID: <52CFB51E.60501@gmail.com> Date: Fri, 10 Jan 2014 09:53:50 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] References: <52C9D788.8060606@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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, 10 Jan 2014 08:54:08 -0000 Hello, Thanks for the post. I could understand the need to spam block an entire /64 instead (a single line in a configuration file) rathern than 2^64 lines each telling an address in that file. Yes, this is relevant when writing other firewalling rules as well. In this sense it is good to have an 'overall' number - like a /64 - to designate one particular link and subnet. And one may like to use other such overall numbers such as a /65 or a /63 to designate these links. And yes, the privacy extensions RFC4941 makes that attacker may use that overall number /64 to generate addresses, and defender may need to use same number /64 to comfortably protect against it. A smarter attacker would use a /63 and a smarter defender too. Alex Le 09/01/2014 18:51, Emmanuel Thierry a écrit : > Hello, > > (first message on these lists, hope it is accurate) > > I'm generally thinking that the /64 limit helps to structure the > address space from the receiver point of view. Let's say i'm running > a mail server which tries to reduce spam by temporarily blacklisting > some senders. if i'm facing spammers who use their IPv6 address > space in a smart way, they will just have to generate RFC 4941 > addresses to exhaust a firewall memory. The pragmatic way to face > such attacks is to blacklist the whole /64, never a unique /128. > > I don't know if it is to be considered as a best practice, but for > these reasons, as a receiver, i personally consider a /64 to be > assigned to a unique link, or at least a network managed by a unique > network administrator. Enforcing this limit in protocol standards > strengthen this assumption. This might be an additional argument for > the "please keep /64 for unique links". > > As a consequence, subdivide a /64 into several prefixes in order to > assign it on several networks might create a risk for devices on one > network to be blacklisted by actions performed by some devices on > another network, in case the whole /64 have been blacklist by a > "pragmatic" receiver. > > Best regards Emmanuel Thierry > > Le 5 janv. 2014 à 23:07, Brian E Carpenter a écrit : > >> Hi, >> >> A group of us put this together following a discussion some weeks >> ago on the v6ops list about the 64-bit boundary in IPv6 addresses. >> Discussion belongs in 6man, please. >> >> This draft is incomplete but we'd welcome input. Let me underline >> an important comment in the introduction: >> >> _The purpose of this document is to analyse the issues around this >> question. We make no proposal for change, but we do analyse the >> possible effects of a change._ >> >> >> Brian + co-authors >> >> -------- Original Message -------- Subject: I-D Action: >> draft-carpenter-6man-why64-00.txt Date: Sun, 05 Jan 2014 13:59:17 >> -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-00.txt Pages : 14 Date : >> 2014-01-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-00 >> >> >> >> >> >> >> >> >> >> -------------------------------------------------------------------- >> >> >> 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 lorenzo@google.com Fri Jan 10 01:00: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 1B80B1ADEB4 for ; Fri, 10 Jan 2014 01:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, 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 4eknCiuhG2U0 for ; Fri, 10 Jan 2014 01:00:08 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id A32A51A1F5B for ; Fri, 10 Jan 2014 01:00:08 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id e14so4896008iej.0 for ; Fri, 10 Jan 2014 00:59:58 -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=IIpkixl/fl85/OQpK+MshVoiVN4oZ8vK9uBAgBVTDLY=; b=UYflAILFa/EZUn+xB1hsCDSoWRHbEstrBZ0A/Uh2whYzgq+tfxuUXGc63mkMQ1AIpW +qHHIgrM3oGCttGfFpKs6/N43HH2ggYvucu5YckkK57mtPoSixvlXy3c5En7UIOXCZW5 vdystL2ThehVNqTXMNqgpgp3NxXumZXF80GYfTfEkz0d8ymB7YqLKWnHglSV8GPzZdeB ZzY1GTtHj3z5zbzj2GSbmkMx1IkLN2dqBDsKqG2s+dqGfuBw7FJqUUpJdZX7Jiufcfnf j8fIlQRE7A+sIHfDYarc/xbfGIlnQv1C7dIx8qC4evu7HkFvhuvgah/FWz/JgthzdtyA WnTw== 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=IIpkixl/fl85/OQpK+MshVoiVN4oZ8vK9uBAgBVTDLY=; b=ms7ISdglBC3efxOqo24e60VQcLnN12Ec69T/7SegVtOGzToEWW6yZcuGLojAqNRIqw nwY4rpTBt5VbFRFBrf9s05LrVsmvZ0z8+JAc8I5H68CKiLoFPrV7xwuwGlUfD8sJpMHW ypRH5FMyIHuVIunMsMgVS7cvx2YS932XOjAUOFhi+yaPUhWTgHXMDew/YmoejH6l6NiG 2Bv3YRjtAFvpSPwF78/f7nURmB+aZlR8JZ1r1AIycNMyoznkDGb7S8DSloVMGusLGBuF ZEUczZluRS6PacYPYokqIQKVeJM8mV3iQfIN0KaCwzItOBVayUbP6DDnHaa8Nlbnhmdl TlUA== X-Gm-Message-State: ALoCoQmhVOFPu95QOargrgblLW74wcqy5nlniM2fLf21U645rZ1JQdGoh7NENnCqYypWq12iBuoaOEHKcSVxvvl5bbWmkCpuueMJjgFtFPNUDnTxuswgbO85Wc7PsGrKBk7f1W7Jfd67wKIWKgBwzd6+ou9Ci26nBAj+eqTzAKNWTctQ4iBfQRhLpuqnYmSKphraZhXVyCQs X-Received: by 10.43.103.137 with SMTP id di9mr187701icc.19.1389344398793; Fri, 10 Jan 2014 00:59:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Fri, 10 Jan 2014 00:59:38 -0800 (PST) In-Reply-To: <52CFAB11.4070404@globis.net> References: <52C9D788.8060606@gmail.com> <52CBE0E6.5020107@globis.net> <52CECC76.1030706@globis.net> <52CFAB11.4070404@globis.net> From: Lorenzo Colitti Date: Fri, 10 Jan 2014 17:59:38 +0900 Message-ID: Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] To: Ray Hunter Content-Type: multipart/alternative; boundary=bcaec5171b6b5c80c204ef99f3bd 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: Fri, 10 Jan 2014 09:00:10 -0000 --bcaec5171b6b5c80c204ef99f3bd Content-Type: text/plain; charset=UTF-8 On Fri, Jan 10, 2014 at 5:10 PM, Ray Hunter wrote: > > IPv6 /64 breaks address scarcity. Wait, maybe I see your position now. You're thinking of a transit network, and you want to limit the number of addresses assigned at the edge so the middleboxes can cope? But I still don't understand. In most cases, in such a transit network you can't do individual machine tracking already because machines are behind NATs. So why is it so important to track every machine in IPv6? Also, I don't understand why you wouldn't use hierarchical addressing and delegation - which is what you might naturally do even in IPv4 - and track ranges instead of individual addresses. Perhaps I don't understand the use case. Can you say more about what sort of networks would need this functionality? --bcaec5171b6b5c80c204ef99f3bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 10, 2014 at 5:10 PM, Ray Hunter <v6ops@globis.net> wr= ote:
IPv6 /64 breaks address scarcity.

Wait, may= be I see your position now. You're thinking of a transit network, and y= ou want to limit the number of addresses assigned at the edge so the middle= boxes can cope?

But I still don't understand. In most cases, in suc= h a transit network you can't do individual machine tracking already be= cause machines are behind NATs. So why is it so important to track every ma= chine in IPv6?

Also, I don't understand why you wouldn't use h= ierarchical addressing and delegation - which is what you might naturally d= o even in IPv4 - and track ranges instead of individual addresses.

Perhaps I don't understand the use case. Can you sa= y more about what sort of networks would need this functionality?
--bcaec5171b6b5c80c204ef99f3bd-- From v6ops@globis.net Fri Jan 10 02:50: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 8A03E1AD67C for ; Fri, 10 Jan 2014 02:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, 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 88KEa1o3z3ts for ; Fri, 10 Jan 2014 02:50:23 -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 CC3BD1ACCEA for ; Fri, 10 Jan 2014 02:50:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 87C678714A3; Fri, 10 Jan 2014 11:50:10 +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 T7PZXk3aeFQc; Fri, 10 Jan 2014 11:50:10 +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 5E9E1870F98; Fri, 10 Jan 2014 11:50:10 +0100 (CET) Message-ID: <52CFD061.6080807@globis.net> Date: Fri, 10 Jan 2014 11:50:09 +0100 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Lorenzo Colitti Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] References: <52C9D788.8060606@gmail.com> <52CBE0E6.5020107@globis.net> <52CECC76.1030706@globis.net> <52CFAB11.4070404@globis.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 10 Jan 2014 10:50:24 -0000 > Lorenzo Colitti > 10 January 2014 09:59 > > IPv6 /64 breaks address scarcity. > > > Wait, maybe I see your position now. You're thinking of a transit > network, and you want to limit the number of addresses assigned at the > edge so the middleboxes can cope? Not just middleboxes. Any process that tracks anything on the basis of an IP address. As a simple example, think of a mail server. Mail servers get abused. They can generally handle themselves. To mitigate resource depletion, postfix runs an "anvil" process in memory. It's a light weight process that simply tracks the number of recent connections in memory from each source IPv4 /32 for a short period. When an individual IPv4 source address sends "too many requests too quickly", postfix does not even open the TCP session with this client. The main postfix process daemon can then continue to serve other well-behaved nodes whilst the rogue node is "shut out". With IPv6 /64, and massively oversized allocations, that defence approach is invalidated, because the anvil process itself becomes a weakness, as it cannot track to /128. You could possibly track at /64, although even that might be too big to handle in memory, with the consequence that one rogue node can create false positives, and take down a whole LAN or site. How do you know that the remote rogue site or rogue host is a single /64 and not a /52 or /56 or /48? Do you track all of the above simultaneously? That has potential for even bigger false positives. In general, if you want to provide a third party access to your mail server or other server for information exchange, you probably want some way of throttling access at the Network Network Interface (NNI) from individual rogue nodes without cutting off well-behaved nodes. Or alternatively, providing preferential access to well-behaved nodes, with WFQ-like solutions. Either way you need to be able to differentiate and track node behaviour at a fairly granular level. Address scarcity has some upside too, in that it limits attack source surface, and allows tracking at node level, and I do not feel that has been sufficiently acknowledged. Registration of "well-behaved nodes" could be another potential approach. Perhaps leveraging AD forests. > > But I still don't understand. In most cases, in such a transit network > you can't do individual machine tracking already because machines are > behind NATs. So why is it so important to track every machine in IPv6? > In the areas I work in, they are inter-enterprise connections to trusted 3rd parties. We try to avoid NAT wherever possible (isn't that the right thing to do? ;) We even use registered addresses on the inside and outside. Security people want as tight a filter as possible. It cannot be the case that a technical problem in a trusted third party spills over into your enterprise, even if this is protected contractually. It's a real nice have to have some upper limit of possible source addresses or sessions for scaling of logs/ scanners/ network intrusion detection systems etc. Otherwise the middleboxes themselves can fall over. It's would also be nice to know who these people are (admittedly we only "know" that today due to some level of trust linked to address allocation schemes e.g. this person is assigned this IPv4address in DHCP or via their SSL VPN connection login). Some of that could be translated into IPv6 with prefix lengths >>64e.g.: an SSL VPN with a /127 = a person. IPv4 and IPv6 is probably not the layer where this identity link should be established, but it's generally all we have today. > Also, I don't understand why you wouldn't use hierarchical addressing > and delegation - which is what you might naturally do even in IPv4 - > and track ranges instead of individual addresses. In an enterprise NNI, or private cloud service, the source and destination ranges would be huge, and the complete list of individual allocations are generally unknown to the other party. The customer might have a /32. The private cloud provider might have a /32. There is generally no hierarchy. These are peer networks of equals. But even then, there's probably only a few tens to thousands machines on each side of the NNI that need to communicate. We generally limit the number of potential source addresses and sessions today by filtering to /32 or /24 or /16 at the NNI plus only allowing certain port numbers. That's massively smaller than granting access to a single IPv6 LAN of /64 for a single port. For example, a single source IPv4 /32 with access to 1 port on 4 destination IPv4 servers is never ever going to be able to saturate a flow-based WFQ session table, even if it is compromised. This source machine can only ever create 4 flows simply because of the ACL at the NNI. A single source machine (that has been compromised ) running IPv6 connected to a /64 using SLAAC + temporary addresses (and which connects to 1 port on 1 server connected to /64 with SLAAC) could easily saturate a flow-based WFQ table, causing service degradation to other well-behaved nodes, simply because the ACL is so much bigger, and the compromised machine can create so many more rogue flows. > > Perhaps I don't understand the use case. Can you say more about what > sort of networks would need this functionality? > Interconnections between enterprises, or within enterprises where different sites are managed by different parties, and avoiding cross contamination of resource depletion attacks sourced from single rogue nodes or sites. Even an ACL for a single /64 for a single port is massively bigger than the biggest access we grant today. Which probably leaves static addressing as the only option. Because alternative defence mechanisms simply aren't in place yet. -- Regards, RayH From ml@sekil.fr Fri Jan 10 02:57: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 15F901AD738 for ; Fri, 10 Jan 2014 02:57:19 -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 AVeUqGZiNONJ for ; Fri, 10 Jan 2014 02:57:16 -0800 (PST) Received: from host1.ip6-networks.net (host1.ip6-networks.net [95.130.10.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDB21AD93D for ; Fri, 10 Jan 2014 02:57:16 -0800 (PST) Received: from [IPv6:2001:660:7301:3728:226:b0ff:fefa:237d] (unknown [IPv6:2001:660:7301:3728:226:b0ff:fefa:237d]) by host1.ip6-networks.net (Postfix) with ESMTPSA id 305C76054E for ; Fri, 10 Jan 2014 11:57:04 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1085) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] From: Emmanuel Thierry In-Reply-To: <52CFB51E.60501@gmail.com> Date: Fri, 10 Jan 2014 11:57:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52C9D788.8060606@gmail.com> <52CFB51E.60501@gmail.com> To: 6man X-Mailer: Apple Mail (2.1085) 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, 10 Jan 2014 10:57:19 -0000 Hello, Thanks for your answer. Le 10 janv. 2014 =E0 09:53, Alexandru Petrescu a =E9crit : > Hello, >=20 > Thanks for the post. >=20 > I could understand the need to spam block an entire /64 instead (a > single line in a configuration file) rathern than 2^64 lines each > telling an address in that file. >=20 > Yes, this is relevant when writing other firewalling rules as well. >=20 > In this sense it is good to have an 'overall' number - like a /64 - to > designate one particular link and subnet. >=20 > And one may like to use other such overall numbers such as a /65 or a > /63 to designate these links. >=20 > And yes, the privacy extensions RFC4941 makes that attacker may use = that > overall number /64 to generate addresses, and defender may need to use > same number /64 to comfortably protect against it. A smarter attacker > would use a /63 and a smarter defender too. Definitely. However, as an attacker, having a smaller prefix than a IPv6 = /64 to exploit for your attack could correspond in IPv4 to use a smaller = prefix than /32. I mean that as a defender, i would use against an attacker who smartly = uses its /63 or smaller, the same techniques than an attacker who have = access to an IPv4 /31 or smaller: blacklist sequentially all IPv6 /64 = that this attacker is using. So anyway, a /64 boundary would at least = help to leverage the problem. This could also be a good hint to network operators or hosters. Some = virtual machine providers (for instance) divide their /64 into smaller = prefixes (i saw /96), which may imply that a bad behavior from one of = their clients might influence other servers. I think there should be a = clear mention of the consequences it may have. Such a mention may help = to promote best practices (TODO: define best practices). Best regards Emmanuel Thierry >=20 > Le 09/01/2014 18:51, Emmanuel Thierry a =E9crit : >> Hello, >>=20 >> (first message on these lists, hope it is accurate) >>=20 >> I'm generally thinking that the /64 limit helps to structure the >> address space from the receiver point of view. Let's say i'm running >> a mail server which tries to reduce spam by temporarily blacklisting >> some senders. if i'm facing spammers who use their IPv6 address >> space in a smart way, they will just have to generate RFC 4941 >> addresses to exhaust a firewall memory. The pragmatic way to face >> such attacks is to blacklist the whole /64, never a unique /128. >>=20 >> I don't know if it is to be considered as a best practice, but for >> these reasons, as a receiver, i personally consider a /64 to be >> assigned to a unique link, or at least a network managed by a unique >> network administrator. Enforcing this limit in protocol standards >> strengthen this assumption. This might be an additional argument for >> the "please keep /64 for unique links". >>=20 >> As a consequence, subdivide a /64 into several prefixes in order to >> assign it on several networks might create a risk for devices on one >> network to be blacklisted by actions performed by some devices on >> another network, in case the whole /64 have been blacklist by a >> "pragmatic" receiver. >>=20 >> Best regards Emmanuel Thierry >>=20 >> Le 5 janv. 2014 =E0 23:07, Brian E Carpenter a =E9crit : >>=20 >>> Hi, >>>=20 >>> A group of us put this together following a discussion some weeks >>> ago on the v6ops list about the 64-bit boundary in IPv6 addresses. >>> Discussion belongs in 6man, please. >>>=20 >>> This draft is incomplete but we'd welcome input. Let me underline >>> an important comment in the introduction: >>>=20 >>> _The purpose of this document is to analyse the issues around this >>> question. We make no proposal for change, but we do analyse the >>> possible effects of a change._ >>>=20 >>>=20 >>> Brian + co-authors >>>=20 >>> -------- Original Message -------- Subject: I-D Action: >>> draft-carpenter-6man-why64-00.txt Date: Sun, 05 Jan 2014 13:59:17 >>> -0800 From: internet-drafts@ietf.org Reply-To: >>> internet-drafts@ietf.org To: i-d-announce@ietf.org >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>=20 >>>=20 >>> 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-00.txt Pages : 14 Date : >>> 2014-01-05 >>>=20 >>> 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. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-carpenter-6man-why64/ >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-carpenter-6man-why64-00 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> -------------------------------------------------------------------- >>>=20 >>>=20 >>>=20 > IETF IPv6 working group mailing list >>> ipv6@ietf.org Administrative Requests: >>> https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >>>=20 >>>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >>=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From evyncke@cisco.com Fri Jan 10 03:23: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 12F9B1ADFE2 for ; Fri, 10 Jan 2014 03:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 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.538, 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 ZDFdHVLnURgv for ; Fri, 10 Jan 2014 03:23:01 -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 5539B1AC4C1 for ; Fri, 10 Jan 2014 03:23:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4705; q=dns/txt; s=iport; t=1389352971; x=1390562571; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vcJZDEDtKghvXTjLaeFRJTVTWQ3rdmEEdRDDihP+cmc=; b=H3TrGUXpvvfYlg4Lyl4riHn6xj7lTb3ym9N9G6rsabo3qa5ZZ5HtApTW btmpDrneGPDs7e8F/PAU/tROjlDJyZYFbuYBmuSGUCzrhhwoKSX9WAbLS 9zZowgn71rR5L5Xl4rRmRN+7mWIIXhIFbHad4X3d2Y0YUxO07uFE7D7o/ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAPTWz1KtJXG+/2dsb2JhbABTBoMLOFa5QYEJFnSCJQEBAQRvCgwEAgEIDgMBAwEBCx0HMhQDBggCBAENBQiHfA3DLheOIgERAQ0SMQcGgx6BEwSJC5A8kGWDLYFxOQ X-IronPort-AV: E=Sophos;i="4.95,638,1384300800"; d="scan'208";a="11886325" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-7.cisco.com with ESMTP; 10 Jan 2014 11:22: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 s0ABMpCq006087 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Jan 2014 11:22:51 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Fri, 10 Jan 2014 05:22:51 -0600 From: "Eric Vyncke (evyncke)" To: Ole Troan , 6man WG Subject: RE: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 Thread-Topic: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 Thread-Index: AQHO5RSJ8254ILuAiU+6fXohkQRkuZp+Ig4g Date: Fri, 10 Jan 2014 11:22:50 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E123857EB6@xmb-aln-x02.cisco.com> References: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> In-Reply-To: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.185.70] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Fri, 10 Jan 2014 11:23:04 -0000 Ole As you asked for a review... here is belated one... (bear in mind that I st= ill have to read the whole thread... I do need an efficient email processin= g brain!) First, centralization and the removal of mcast traffic has already an impac= t on security, security (and operation probably) people tend to prefer stro= ng centralized architecture vs. decentralized ones because they are easier = to control. Of course, the drawback is 'single point of failure' Sometimes, the ID looks more like a marketing document "optimization will b= e highly effective" ;-) Also, too many sentences & concepts that are releva= nt in the past 6lowpan WG. Some acronyms are used (NCE) before being define= d (if at all for neighbor cache entry) Mandatory use of SLAAC and EUI-64. In the contex of privacy (and possible o= bsolete EUI-64 + stable privacy address), I wonder whether it is still usef= ul to rely on EUI-64. I guess that changing to a stable but private IID wou= ld be enough. The text is not really clear whether this EUI-64 is only for = LLA or for any global address. In section 4, I failed to understand the link between ULA & EUI-64. Section 7.1, it is also unclear for me when talking about a unique address = per host, does this include LLA as well? Or ULA (cfr low end CPE) in combin= ation with GUA? Most of the document seems to indicate only EUI-64 while th= is section seems more open (then I remove previous comments of course). If = EUI-64 is 'just' used as a node identifier/unique-ID (and not linked to any= IPv6 address) why not simply using DHCP DUID? Or even the layer-2 address = (assuming that this one is unique & stable). Then, I strongly suggest remov= ing all reference to EUI-64 and use 'opaque node unique ID'. There is the mention of 'transaction' but to me it appears as a shoot a pac= ket and hope that it is not lost and that the receiver gets it... Be sure to mention unauthenticated WiFi DoS against the router table as a n= ode could easily change of MAC address and fill the table. Bringing the who= le network down (including intra-link traffic).=20 Also, the behavior should be explained when the NEAR receives ARO with diff= erent lifetimes, which ones to keep? Suggestion: If the 'index' to the tabl= e is no more EUI-64 (which is guessable) but an opaque/random but stable id= entifier (such as DHCP DUID), then the NEAR could overwrite the existing en= tries only when NS/ARO has the right identifier/cookie? 11.1 another way to prevent NDP cache exhaustion is simply not doing NS/NA = when NEAR receives a packet to an unknown destination. Who announced mixed mode? Can this be downgraded by sending a fake RA witho= ut the E-bit? Hence, being no more efficient? No clue on how to fix it thou= gh ;-) Not clear to me whether CGA is supported... I would guess not, then it shou= ld be stated somewhere 15. Again, I am not really a big fan on relying on EUI-64 addresses... see = above. Then, DAD is more important. Later in the section, it is talked abou= t 64-bit MAC addresses... which is unusual on legacy W/LAN ;-) 17.2 should really be closer to the section describing mixed-mode operation 19 it makes this I-D really close to 6lowpan and similar use cases while th= ere are benefits of this I-D applicable outside of 6lowpan as explained in = appendix A Final recommendation: remove the use cases and create a problem statement I= -D because, again, the problem is wider than NS/NA (too many mcast RS/RA an= d other protocols such as mDNS). Hope this helps -=E9ric > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ole Troan > Sent: mardi 19 novembre 2013 11:46 > To: 6man WG > Cc: 6man Chairs > Subject: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient- > nd-04 >=20 > All, >=20 > There was moderate support to adopt this draft at the working group > meeting in Vancouver. > This is an adoption call to confirm the result of the hum at the meeting. >=20 > Please provide a view with reasons as to whether the WG should adopt this > or not. >=20 > This message starts a one week 6MAN Working Group call on adopting: >=20 > Title : Wired and Wireless IPv6 Neighbor Discovery > Optimizations > Author(s) : S. Chakrabarti, E. Nordmark, P. Thubert, M. Wasserman > Filename : draft-chakrabarti-nordmark-6man-efficient-nd-04 > Pages : 31 > Date : 2013-10-22 >=20 > http://tools.ietf.org/html/draft-chakrabarti-nordmark-6man-efficient-nd= - > 04 >=20 > The call ends on November 26th, 2013. >=20 > Regards, >=20 > Bob Hinden & Ole Tr=F8an From lorenzo@google.com Fri Jan 10 05:58: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 1CAA51AE033 for ; Fri, 10 Jan 2014 05:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.316 X-Spam-Level: X-Spam-Status: No, score=-1.316 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RP_MATCHES_RCVD=-0.538, 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 lKNngWHxcCpz for ; Fri, 10 Jan 2014 05:58:47 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C29D11AE008 for ; Fri, 10 Jan 2014 05:58:47 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id x13so5126991ief.20 for ; Fri, 10 Jan 2014 05:58:37 -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=UbYGX8BFSI679QRrSFC5I5nAcUJTD3NFUblzjH1sbi4=; b=lQ+yPdXhM7sBuggSpec/Vyt38Y4+ZZaGvrRxLbU6q0BmOIfuuJOO5HNQWlAW4z5pOR RSekk0At/8j0vLg2Tqcv2QzDGldzneCNON6WWVZqsJ8HI5UPl6d31A9j0odzrvSSoKdD 9xM/s261brfdpGoo/LGJstRgzBRb1HWJRK0FAe0bi2jlFsulTjB925WzEFBc15GgAyWf GpMmF72F7eHrrZz2lkuqfozweic0F4IIVZL7aIqmAvZRTz8hVO5X6nrVK0RSufQNd9hB cqmqPBhSEATC4lJl0DcvnLbTHXqeY5uhAgWRnYbKSzrM8x+o9NuIL5IL0ODJ+Se41qoc m+zQ== 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=UbYGX8BFSI679QRrSFC5I5nAcUJTD3NFUblzjH1sbi4=; b=Rd93Z0q8JFar87fcLqZV2eFEAVpsvEfxburig1ZwD+T70zw3EOpmTjkIpOV79O02nQ /8tuTJ79dKC2AOZYKdYN9QJqYUtGd6nhaZhYhPfJ2KpGTJjKnj3zMzE38IT2wx94WRco ZdwNFOlKJeri4sxliCYYtP8fwSS+ButJfzf9fM47PAhtZjKHtrW6W47GkJd8aQE9x+rx uFVeINTCFfIPigy2hg9F43ercNEfLULnYHROjNYSs+2eiFtpNp59RiXL49Qi7b/qmjmk UD3l15jlCAOCOHipv9KX3XhVfy5PypZ0XtxhWpuVP/nTqhfpOsZgszl65mNq0r3FI8tq jvBg== X-Gm-Message-State: ALoCoQmRCnD/HAPwpRnjRh/n/jbY24oMOqgKM6/dmUHbtZMGNPSjQny0yK8OqeKE9kb8Mm39CJ4PmOYZR8j8L68319gAvSOiMxfTFNFBTzGKVaOC1fF26Ghm683Ag0XMoL4fbXlSK41raJ47ySTdcr0xZL/qPsQ5FO51xBSS/0tb7aAUjTmca/SQD3c8rJqhYlFsFTP25a1i X-Received: by 10.50.61.137 with SMTP id p9mr3446423igr.45.1389362317749; Fri, 10 Jan 2014 05:58:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Fri, 10 Jan 2014 05:58:17 -0800 (PST) In-Reply-To: <52CFD061.6080807@globis.net> References: <52C9D788.8060606@gmail.com> <52CBE0E6.5020107@globis.net> <52CECC76.1030706@globis.net> <52CFAB11.4070404@globis.net> <52CFD061.6080807@globis.net> From: Lorenzo Colitti Date: Fri, 10 Jan 2014 22:58:17 +0900 Message-ID: Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] To: Ray Hunter Content-Type: multipart/alternative; boundary=047d7bdca5dc6a272304ef9e1f6f 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: Fri, 10 Jan 2014 13:58:50 -0000 --047d7bdca5dc6a272304ef9e1f6f Content-Type: text/plain; charset=UTF-8 On Fri, Jan 10, 2014 at 7:50 PM, Ray Hunter wrote: > > When an individual IPv4 source address sends "too many requests too > quickly", postfix does not even open the TCP session with this client. > The main postfix process daemon can then continue to serve other > well-behaved nodes whilst the rogue node is "shut out". > > With IPv6 /64, and massively oversized allocations, that defence approach > is invalidated, because the anvil process itself becomes a weakness, as it > cannot track to /128. > You could possibly track at /64, although even that might be too big to > handle in memory, with the consequence that one rogue node can create false > positives, and take down a whole LAN or site. > But Postfix mail servers are exposed to the Internet. And the Internet already connects tens of millions of users that have /56 prefixes at their beck and call to mount an attack. Obviously, the naive approach of tracking to /128 is not going to scale. But neither does the naive approach of storing BGP tables in linked lists. Fortunately, router implementations use patricia tries and hash tables, and equivalently, fortunately it's possible to do better than to track at the /128 level. > How do you know that the remote rogue site or rogue host is a single /64 > and not a /52 or /56 or /48? > Do you track all of the above simultaneously? That has potential for even > bigger false positives. > Three minutes of thought suggest that you could have separate /64, /56 and /48 tables (or whatever) and when a certain threshold of entries in one table match the entries in the table one level shorter, delete them and block the covering prefix at the shorter prefix level. Thinking about it for three hours instead of three minutes will probably produce several more sophisticated ideas - one example is looking for evenly-spaced spikes in prefix usage patterns in historical log data to detect ISP assigned prefix sizes in particular blocks, and then track that region of the IPv6 space at that block size. > In general, if you want to provide a third party access to your mail > server or other server for information exchange, you probably want some way > of throttling access at the Network Network Interface (NNI) from individual > rogue nodes without cutting off well-behaved nodes. > Why individual rogue nodes? In most networks (maybe yours is an exception; but in general, anything exposed to residential users), you can't see the nodes. You can see NAT pool IPs. So we're already tracking by the block, even in IPv4. > Address scarcity has some upside too, in that it limits attack source > surface, and allows tracking at node level, and I do not feel that has been > sufficiently acknowledged. > If address scarcity is what you want, there's a well-supported, ubiquitously deployed protocol you can use: IPv4. Unfortunately, its main problem is... address scarcity. We're trying to fix that problem. We can't fix it by creating more scarcity. It's would also be nice to know who these people are (admittedly we only > "know" that today due to some level of trust linked to address allocation > schemes e.g. this person is assigned this IPv4address in DHCP or via their > SSL VPN connection login). Why can't you associate an SSLVPN connection login with a /64? It's still one login. > Some of that could be translated into IPv6 with prefix lengths >>64e.g.: > an SSL VPN with a /127 = a person. > Why a /127? Why not a /64? It's the same number of state entries - one per login. And a /127 (or even a /128) is not one machine. It could be one machine, or it could be a distributed cluster of machines running a transparent TCP proxy for 100000 clients. For example: star.c10r.facebook.com has IPv6 address 2a03:2880:f00f:300:face:b00c:0:1 You don't think that's one machine, right? For example, a single source IPv4 /32 with access to 1 port on 4 > destination IPv4 servers is never ever going to be able to saturate a > flow-based WFQ session table, even if it is compromised. This source > machine can only ever create 4 flows simply because of the ACL at the NNI. > But WFQ scales in terms of the buffer size (i.e., the total length of the queue), not in the number of flows, right? If what you're queueing is packets, then the queue is not unbounded and there is no scaling issue. > Even an ACL for a single /64 for a single port is massively bigger than > the biggest access we grant today. Which probably leaves static addressing > as the only option. Because alternative defence mechanisms simply aren't in > place yet. > In this case, what you want DHCP for is not tracking - it's predictability. You want to assign a given client an address that will pass through the security pinhole. There's nothing stopping you from doing this even if the client is on a /64 subnet with SLAAC turned on - just assign addresses via DHCPv6 or statically, configure the firewall to pass one /128, and configure the application to use the "magic" address you gave it. You don't need to create scarcity for that to work; it would work perfectly well if the host had a SLAAC address and 5 temporary addresses for Internet access, for example. --047d7bdca5dc6a272304ef9e1f6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 10, 2014 at 7:50 PM, Ray Hunter <v6ops@globis.net> wr= ote:
When an individual IPv4 source address sends "too many requests too qu= ickly", postfix does not even open the TCP session with this client. The main postfix process daemon can then continue to serve other well-behav= ed nodes whilst the rogue node is "shut out".

With IPv6 /64, and massively oversized allocations, that defence approach i= s invalidated, because the anvil process itself becomes a weakness, as it c= annot track to /128.
You could possibly track at /64, although even that might be too big to han= dle in memory, with the consequence that one rogue node can create false po= sitives, and take down a whole LAN or site.

But Postfix mail servers are exposed to the Internet. And the Internet= already connects tens of millions of users that have /56 prefixes at their= beck and call to mount an attack. Obviously, the naive approach of trackin= g to /128 is not going to scale. But neither does the naive approach of sto= ring BGP tables in linked lists. Fortunately, router implementations use pa= tricia tries and hash tables, and equivalently, fortunately it's possib= le to do better than to track at the /128 level.
=C2=A0
How do you know that the remote rogue sit= e or rogue host is a single /64 and not a /52 or /56 or /48?
Do you track all of the above simultaneously? That has potential for even b= igger false positives.

Three minutes of= thought suggest that you could have separate /64, /56 and /48 tables (or w= hatever) and when a certain threshold of entries in one table match the ent= ries in the table one level shorter, delete them and block the covering pre= fix at the shorter prefix level. Thinking about it for three hours instead = of three minutes will probably produce several more sophisticated ideas - o= ne example is looking for evenly-spaced spikes in prefix usage patterns in = historical log data to detect ISP assigned prefix sizes in particular block= s, and then track that region of the IPv6 space at that block size.
=C2=A0
In general, if you want to provide a thir= d party access to your mail server or other server for information exchange= , you probably want some way of throttling access at the Network Network In= terface (NNI) from individual rogue nodes without cutting off well-behaved = nodes.

Why individual rogue nodes? In most networ= ks (maybe yours is an exception; but in general, anything exposed to reside= ntial users), you can't see the nodes. You can see NAT pool IPs. So we&= #39;re already tracking by the block, even in IPv4.
=C2=A0
Address scarcity has some upside too, in = that it limits attack source surface, and allows tracking at node level, an= d I do not feel that has been sufficiently acknowledged.

If address scarcity is what you want, ther= e's a well-supported, ubiquitously deployed protocol you can use: IPv4.= Unfortunately, its main problem is... address scarcity. We're trying t= o fix that problem. We can't fix it by creating more scarcity.

It's would also be nice to know who these people are (admittedly we onl= y "know" that today due to some level of trust linked to address = allocation schemes e.g. this person is assigned this IPv4address in DHCP or= via their SSL VPN connection login).

Why can't you associate an SSLVPN connection login = with a /64? It's still one login.
=C2=A0
Some of that could be translated into IPv6 with prefix lengths >>64e.= g.: an SSL VPN with a /127 =3D a person.

Why a /127? Why not a /64? It's the same number of state entries - on= e per login. And a /127 (or even a /128) is not one machine. It could be on= e machine, or it could be a distributed cluster of machines running a trans= parent TCP proxy for 100000 clients. For example:

sta= r.c10r.facebook.com has IPv6 address 2a03:2880:f00f:300:face:b00c:0:1

You don't think that's one mach= ine, right?

For example, a single source IPv4 /32 with = access to 1 port on 4 destination IPv4 servers is never ever going to be ab= le to saturate a flow-based WFQ session table, even if it is compromised. T= his source machine can only ever create 4 flows simply because of the ACL a= t the NNI.

But WFQ scales in terms of the buffer size= (i.e., the total length of the queue), not in the number of flows, right? = If what you're queueing is packets, then the queue is not unbounded and= there is no scaling issue.
=C2=A0
Even an ACL for a single /64 for a single port is massively bi= gger than the biggest access we grant today. Which probably leaves static a= ddressing as the only option. Because alternative defence mechanisms simply= aren't in place yet.

In this case, what you want DHCP for is no= t tracking - it's predictability. You want to assign a given client an = address that will pass through the security pinhole.

There's nothing stopping you from doing this even if the client is= on a /64 subnet with SLAAC turned on - just assign addresses via DHCPv6 or= statically, configure the firewall to pass one /128, and configure the app= lication to use the "magic" address you gave it. You don't ne= ed to create scarcity for that to work; it would work perfectly well if the= host had a SLAAC address and 5 temporary addresses for Internet access, fo= r example.
--047d7bdca5dc6a272304ef9e1f6f-- From brian.e.carpenter@gmail.com Fri Jan 10 14:27: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 A65561ACCD8 for ; Fri, 10 Jan 2014 14:27:27 -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 KQcANFJC61V9 for ; Fri, 10 Jan 2014 14:27:25 -0800 (PST) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 39E1E1ACC84 for ; Fri, 10 Jan 2014 14:27:25 -0800 (PST) Received: by mail-pd0-f172.google.com with SMTP id g10so5093788pdj.17 for ; Fri, 10 Jan 2014 14:27:15 -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=8RX1F/xPu6b9ipioIUQT4wt8B4qt1H5tIMGdsmPpgy0=; b=JBmo4o09Cu9fMFP3OS49FkOiPo1iLmnNr6LsCARqunAnGGcsIW3EQWC0DmvgpudXSf hwNNNopSqJWyJV3M2BpQYoRb9dz+RrgJZAo1YJXuAV9SKU35Gto/wgrGn8MQuxiVWWVZ PajI7V8EOSYsBh1e4+ngLuTuzi/GwMtibhKZm/ilkz2w35Dy3jW/N6QVP7TGhaayMNUc iDPDm4uSAZX8GJNHCYo9ckTW6QGeSb+k+YYJxJTz/sQpU1XFraaHIloT+0ewXcmt2jzh 1H10pO3uCuxOgpKPFENEGOkP7QS1jm4RcFE0ZmyWo5jFiNAB0c9Mw62pfbm4i7ePwGWF 1wIQ== X-Received: by 10.66.118.71 with SMTP id kk7mr14557615pab.14.1389392835331; Fri, 10 Jan 2014 14:27:15 -0800 (PST) Received: from [192.168.178.21] (154.199.69.111.dynamic.snap.net.nz. [111.69.199.154]) by mx.google.com with ESMTPSA id fk4sm25191702pab.23.2014.01.10.14.27.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Jan 2014 14:27:14 -0800 (PST) Message-ID: <52D073CC.6070205@gmail.com> Date: Sat, 11 Jan 2014 11:27:24 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Hunter Subject: Zillions of addresses [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] References: <52C9D788.8060606@gmail.com> <52CBE0E6.5020107@globis.net> <52CECC76.1030706@globis.net> <52CFAB11.4070404@globis.net> In-Reply-To: <52CFAB11.4070404@globis.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: Fri, 10 Jan 2014 22:27:27 -0000 > But problems in their /48 with a rogue node assigning zillions of addresses and creating zillions of sessions should not spill over into the rest of the network managed by others. Who says that is a rogue node? It sounds like perfectly legitimate behaviour for a virtual machine environment that is designed to virtualise at layer 3. If you want those VM addresses to be unguessable for an off-path attacker, you might well spread them sparsely across a /64. Anyway -- I am not seeing much in this thread that suggests text changes in the -why64 draft (which is intended to be factual). I take Ray's original point that there *might* be other risks than ND exhaustion, and we'll add that to the next version. Regards Brian On 10/01/2014 21:10, Ray Hunter wrote: >> Lorenzo Colitti >> 10 January 2014 06:01 >> >> >> Ideally, that ability to control/register active /128's should not >> rely on cooperation of L2 switches or other LAN functionality that >> requires purchasing new switches, or constant MIB scanning. >> >> I think that's a valid problem statement, and assigning >>/64 >> (purposefully breaking SLAAC, whilst deploying stateful DHCPv6, or >> static addressing) is one way to address that problem. >> >> >> In your network you are free to assign addresses exclusively using >> DHCPv6. >> >> *However* - if you are doing this for the purpose of tracking, that >> only makes any sense at all if the current switches you have (since >> you've already said you're not going to buy new ones) can snoop DHCPv6 >> requests for address assignments enforce IPv6-to-MAC address mappings. >> >> Do they? >> > You are apparently imposing a model which assumes a single management > vendor is responsible right up until the edge of the network at port level. > > That is rarely true in any enterprise I've worked on. They are not my > customer's switches. They don't manage them at all. They subcontract > that to multiple parties. > > In the case of multiple management providers, people need to protect > their own services from the failings of others. > > If a site is under autonomous management (e.g. trusted 3rd party) then > they may be assigned a /48 in your model. > > OK they're responsible for their own /48 and they can suffer the > consequences of poor management of devices in their site. > > But problems in their /48 with a rogue node assigning zillions of > addresses and creating zillions of sessions should not spill over into > the rest of the network managed by others. > > WFQ QoS (and many other processes which requires tracking of individual > sessions or IP addresses) running in another vendor's network should not > fail because of a single node in a single 3rd party network swamps an > address/session table. > > I think that people need some way of limiting the number of active > /128's at the network-network interface. It would be even better if we > could either register or control to the /128 and identify those to a > host or user. > > One way of doing that is to agree with trusted 3rd party sites (which > generally only have a tiny number of hosts allowed to communicate across > the boundary) to only assign an agreed /120 out of their /48 allocation, > which requires prefix lengths >>64 (this ID) or at least the ability to > apply ACL filters >> /64. > > Another way is source address validation at the edge, with limits > assigned on a first come first served basis. > > Another is to ban all processes that need to track an individual IPv6 > address. > > Another is to contract that the site themselves are responsible for > limiting resource depletion attacks, but I'd still want some protection > on the receiving side. > > I'd rather be tracking the 100K nodes that I know should be on the > network out of a potential 24*2^16 addresses, rather than trying to stop > a 100 zillion anonymous nodes who I can't even identify so that the 100K > can work. > > DHCP has been successfully implemented in multi-vendor environments. The > local LAN manager/outsourcer only has to configure up the LAN interface > either the correct IP address and subnet mask, and point a DHCP proxy at > a regional server (managed by someone else) They can make changes within > a site autonomously without bothering the central team, and it all just > works. > > DHCPv6 potentially can provide a form of centralised registration (and > then be linked to admission control, or at least give cooperating end > nodes a higher QoS than unidentified end nodes) and support a similar > operations model. > You could also allocate a /64, configure a DHCPv6 address pool to assign > addresses from a range >>64 and apply and ACL, or assign and allocate >>>64 prefix length (which seems easier). > > > Because if they don't, disabling SLAAC gives you no security at all, > because malicious hosts on your network will still be free to create and > use arbitrary IPv6 addresses, which you will not be able to track. In > fact, this gives you the same level of security as you could by > disabling privacy addresses and using autoconf - malicious hosts can > still do what they want, and for well-behaved hosts, instead of having > the MAC address in the IPv6 address, you now have to go and get it from > the DHCPv6 server logs. Lose/lose. > > That is also a problem. The assumption seems to be that there has been > of smart nodes and a dumb network that does not run any processes > requiring differential services or that tracking of individual end hosts > is universally bad. > > But I thought we'd established that we're not exclusively talking about > forcing use of particular addresses for all machines, rather > establishing which nodes are genuinely active, and attempting to > establish centrally what machine they are being used by. >> >> Or - as Tim points out, SNMP scraping will do this securely for you >> today, and vendors are already building better and more scalable >> address registration notification features (syslog, etc.) into switches. > Not everyone allows SNMP access from other management vendors in a multi > vendor environment. Not everyone feeds syslog to other management vendors. > Again, you are imposing an alien operations model. It imposes polling, > It imposes inter-vendor cooperation and access to all remote devices via > a management protocol. > Every time a switch on any one of 1000 sites changes, you're going to > have to update your central poller. A central registration model avoids > that overhead. >> And if you're not doing this for the purpose of tracking, then why are >> you doing it? Is it just because it's what you do in IPv4? If so, then >> sorry, that's not a valid technical argument. > At the risk of repeeating myself: helpdesk call correlation, problem > correlation, log correlation, ability to track to /128 (for future > filtering or tracking or resource protection of processes and devices > within the network that rely on databases or caches keyed by IP address) > > In IPv4, this protection happens automatically due to address scarcity, > without doing anything else. > > IPv6 /64 breaks address scarcity. > > From ayourtch@gmail.com Fri Jan 10 15:58: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 B61371AE0E2 for ; Fri, 10 Jan 2014 15:58:11 -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 nvfFMm4MDmjp for ; Fri, 10 Jan 2014 15:58:10 -0800 (PST) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B6B171ACC8A for ; Fri, 10 Jan 2014 15:58:09 -0800 (PST) Received: by mail-qa0-f43.google.com with SMTP id k15so4776847qaq.30 for ; Fri, 10 Jan 2014 15:57:59 -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=lDxhEWPQv5MgYFKcVpLzrlr0azblcRYF2hc95Mdoul4=; b=MwOx7StwHkeNvwQDtyk+o4b65huzqZw18XpMo5eTrkdMdM7d/8ydGHxpaW8fHuIbC0 QbwZ6i7LzcjJ4RuCY2tXWfFtQvz8EnHy6uiH5zvwdSwGtL8IdfW9XSJusYX1FxVY8jg/ Pa2tt0GcIvi9mdccANAdhvzjtbT9FX1tVIa9mNCxy5lq9ErdoRtTGmNFaESTuVaPkr0G 3H/eVEMqAac9eouOodi5tbFAv9NHYhh8QwJD3OuodLDSRdM1eA29iKiIBkYJi/n5REnT ObaRxRlyNYb3UymAI21/sPbMBo/V64pR6GFi1sYnVxRstfdABHMxoFem1nwuNLbYQyQV 8J5A== MIME-Version: 1.0 X-Received: by 10.49.52.102 with SMTP id s6mr13175744qeo.60.1389398279550; Fri, 10 Jan 2014 15:57:59 -0800 (PST) Received: by 10.96.133.39 with HTTP; Fri, 10 Jan 2014 15:57:59 -0800 (PST) In-Reply-To: <0D19594A-F434-44C8-B02D-67B6FD401A9E@steffann.nl> References: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> <0D19594A-F434-44C8-B02D-67B6FD401A9E@steffann.nl> Date: Fri, 10 Jan 2014 23:57:59 +0000 Message-ID: Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: Sander Steffann Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Fri, 10 Jan 2014 16:17:57 -0800 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 10 Jan 2014 23:58:12 -0000 Sander thanks! all, first off - apologies for the length of this mail, I tried to structure it so that first I talk about what I think the multicast-related issues are on the WiFi (what Sander asked), and then add a few thoughts overall that I finally have managed to put on paper. So feel free to doze off while reading, as you see fit :-) There are two main issues related to "too much" multicast packets on WiFi: 1) Indeed the multicast frames are transmitted at a lower rate (and as the SO entry tells, also the mileage varies) That said, 1Mbps rate is becoming somewhat of a corner case - usually those rates are disabled due to their general poor throughput and realistically it will probably be 11Mbps rate, the highest for 802.11b devices - or 12Mbps in case you do not support 802.11b-only clients (most of the client gear today supports either 802.11g or 802.11n). So this becomes somewhat less of a problem, though considering that "WiFi guys" are generally reluctant to even advertise an extra SSID with no clients (overhead being 10pps of broadcasted beacon frames at low data rate), you will notice every PPS helps. Andrew von Nagy has a great calculator telling exactly how much it helps, for the extra SSID case, at [3]. But I think we can creatively equate it to each additional 10pps of all-hosts multicast. As you see, it's noticeable. 2) The bigger problem - the battery life: WiFi is a pretty expensive thing to do, power-wise. To help extend the battery, the mobile devices try very hard to shut off the radio whenever they can. The wireless station would go to sleep, and inform the AP about this fact - so the AP can buffer the frames for it [1]. Further optimizations in this area were introduced by 802.11e (WMM-PS) [2], where the frames destined to workstation could be transmitted more efficiently and radio duty cycle is reduced. Spontaneous all-hosts multicasts interfere with these mechanisms, thus the battery drain on the devices is much higher - especially in a typical network where the mobile devices move, and might trigger an RS/RA on each L2 roam between BSSIDs. So, if a host typically gets one packet burst per minute, and, say, it decides to put the radio to sleep 15 seconds after no packets, it will have 25% power consumption compared to the case where the same host needs to process a 0.1pps (one packet in 10 seconds) of all-hosts mcast. So, that means if the gadget survives 8 hours in a quiet home network, now it will die after 2 hours [4]. This issue especially manifesting itself in the high-density/event wifi deployments, generally people are very upset when their gadgets run out of juice. All of the above said: both of these issues are already somewhat taken care of by the tweaks at the data-link layer: e.g. my employer's wifi gear will replicate the RAs as unicast packets over the radio, and also if so configured, it can both block the excessive multicast RA sent to all-hosts, as well as track which clients were originating the RS, and prune the unicast over-the-air delivery to only those hosts that have just sent "unanswered" RS messages. (This is fixable much easier at the router by sending solicited RAs unicast, but this is a different story). Also, both ARP and ND are proxied to some extent, given that the controller (a box that centrally handles the traffic from APs and their configurations) has a very good awareness of the clients and can judge about their addresses to some extent by their traffic. For the roaming: any WiFi network with more than 1 access-points does a lot of roaming stuff at L2 already, tries to do it as fast as possible, and it's even standardized in 802.11r [6], so approaching it with an L3-only hat on as if it is a brand new problem, is suboptimal IMHO. I hear someone saying: "Yes, but this is all about wireless, DC is all different story - it's all switches, they don't hold the state!" - yes and no. The hosts in the DC are increasingly VMs, which run on top of the hypervisor - and is there something with *more* state related to the host than the hypervisor running such a host ? This is my concern with adding a relatively large chunk of a protocol on top of the existing crutches: how much does it get us compared to what we have already, and at what cost... To summarize: I do think the problems this draft talks about are real. But after a *lot* of deliberation I think the solution should be more lightweight and more incrementally implementable/deployable than what the draft offers wholesale. At a non-100% deployed rate the approach in the draft will add more headaches to the administrators and users than help IMHO. Now, while I have a mic, let me take my napkin with some sketches ... ;-) Maybe worth to split the problem area into smaller subsets and see whether a "cheaper" solutions are possible. Let's first take the "multicast RAs" problem, and assume we do the below steps: a) Allow the environments that wish to do so, to send solicited RAs unicast. (standard already permits to do so). b) Have the hosts restart the Resilient RS [5] process at 1/2 or so of router lifetime expiry: the router now can have the heuristic to know which hosts are supporting the "unicast RA update" mechanism *and* did not receive the periodic RA which would have been sent usually at 1/3 the lifetime expiry (three RAs per lifetime rule of thumb). c) bump up the allowable MaxRtrAdvInterval and AdvDefaultLifetime to their maximum theoretically possible values (spec says the hosts should already be able to handle those, I did not test though) - this would allow to further reduce the periodic RA frequency, from 2.5 hours today to ~18.2 hours, or, if we feel adventurous, put all-ones to be a "solicited-only RAs by default" - thus, unless another router sends an RA with different lifetime, refreshing the router info becomes host-driven, with an option for a router to override at any time. These steps take care of the "multicast RA" problem. But again, also, each of them by itself brings incremental usefulness, and is doable on a single device => no "chicken and egg", they gradually shrink the issue - and are compatible with the existing tweaks that solve the same problem (in a more layer-violating way). Now let's think of updating the various caches while roaming: d) we could make a tweak to allow the solicited unicast RA from (a) to contain an arbitrary blob created by the router, and require that the "router refresh" (b) RSes from the host to contain this blob from the router that they are currently using as the default router. e) Request the host to send this "refresh" RS ahead of time if they get a notification from a data-link layer that a link has changed. AFAIK this is something that already happens today, at least for some hosts. f) Define the magic pixel dust that is put into a blob by a router, such that the receiving router could un-dust this blob in the subsequent "refresh" RS and do the necessary notifications/updates (this protocol would be entirely at router-switch side and would not need any more mods by hosts). These three would help with quicker refresh of L3/L2 data while roaming, and also each of them brings some incremental benefits of various sorts, is doable on a single device, and can make use of the lower-layer optimizations if necessary. NB: the above does not take care of the "defending the host's address on behalf of the sleeping node" problem. I think there is a good use in splitting it as a separate function, because "sleeping node" can be rather a "node on the very expensive bandwidth" - so something developed here could also apply to e.g. 3G/LTE devices, instead of today's diode firewalls - and would not necessarily be limited to current segment, nor hard-coupled with the router function. But the magic pixel dust from (f) above could supposedly be a building block for such a protocol of for a part thereof. NB2: the above is nothing more than a napkin-sketch of what I think may work, I have not thought about the corner cases of it, etc. If the community thinks it would be interesting to transfer the above from a napkin onto a draft or drafts, I could do it. If you made it to here - thanks for reading ! :-) [1] http://en.wikipedia.org/wiki/Delivery_traffic_indication_message [2] http://en.wikipedia.org/wiki/IEEE_802.11e-2005#APSD [3] https://www.dropbox.com/s/imjrugrpyyscd7/Wi-Fi%20SSID%20Overhead%20Calculator.xlsx [4] this is a SWAG. I do not have hard data, just the theoretical knowledge of what is at play, and the empirical observations from various networks. The activity to measure it is on my todo list. [5] http://tools.ietf.org/html/draft-ietf-6man-resilient-rs-02 [6] http://www.cwnp.com/cmsAdmin/uploads/802-11_rsn_ft.pdf --a On 1/9/14, Sander Steffann wrote: > Hi, > > Op 9 jan. 2014, om 14:33 heeft Lorenzo Colitti het > volgende geschreven: > >> On Thu, Jan 9, 2014 at 9:44 PM, Mikael Abrahamsson >> wrote: >> >> They would be rate-limited, just like any other ND packets on any >> implementation worth its salt. I think an NS is 72 bytes including ICMPv6 >> header; if so, then even if you send out 500 of them per second, that's 36 >> kB/s. What sort of link has a problem carrying 36 kB/s? How many NSes per >> second can routers send out anyway? >> >> I don't know, people seem to indicate that there is a problem with >> multicast pps on wifi links. I haven't seen any hard data on this, it was >> just my interpretation that this was considered a problem. >> >> Knowing nothing about this, I will cite http://stackoverflow.com/a/4341485 >> , hoping that the draft authors will come along with more detailed data >> (which hopefully they have already presented to justify their use case and >> which I missed): >> >> === >> With unicast the access point tracks what data rate every particular >> receiver can reliably receive at, and sends about that rate. With >> multicast the access point does not know which receivers are interested in >> the data, so simple access points send the data at the slowest possible >> rate (1Mb/s). Better implemented access points may send the data at the >> rate that the slowest connected client is using, and the best access >> points use IGMP snooping to see who's receiving each IP multicast stream, >> and they will choose the slowest rate out of the receivers for that >> stream. >> === >> >> Even 1Mbps is still a fair number of ND packets though. > > I think the issue is that, while 1Mbps is enough for ND, it is lowering the > speed for the whole channel. So in the time that the 72 byte packet is sent > at 1Mbps there *could* have been 3888 bytes at 54Mbps. And I have no idea if > the speed switch itself takes up any time. > > I know that Andrew Yourtchenko has some real life experience with this > stuff, so I'll put him in CC in case he has something to add. > > Cheers, > Sander > > From samita.chakrabarti@ericsson.com Fri Jan 10 18:57: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 012B41AD937 for ; Fri, 10 Jan 2014 18:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GC6qkzD99Npv for ; Fri, 10 Jan 2014 18:57:25 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id E72011AC82A for ; Fri, 10 Jan 2014 18:57:24 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-85-52d0b30a9ead Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 1E.36.04556.A03B0D25; Sat, 11 Jan 2014 03:57:14 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0347.000; Fri, 10 Jan 2014 21:57:13 -0500 From: Samita Chakrabarti To: "Eric Vyncke (evyncke)" , Ole Troan , 6man WG , =?utf-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtvIChheW91cnRjaEBnbWFpbC5jb20p?= Subject: RE: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 Thread-Topic: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04 Thread-Index: AQHO5RSHI47a5UQsiE68Y1syr/NqV5p+dj8AgACr7AA= Date: Sat, 11 Jan 2014 02:57:12 +0000 Message-ID: References: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> <97EB7536A2B2C549846804BBF3FD47E123857EB6@xmb-aln-x02.cisco.com> In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E123857EB6@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXRPlC7X5gtBBhPnyFos6Gxitdi26QGL xZf9CxgtXp59z2QxuW0FmwOrx5TfG1k9Dh77yOixc9Zddo8lS34yeXy5/JktgDWKyyYlNSez LLVI3y6BK+Pjvg6WglWsFTOnbmFvYJzB2sXIySEhYCKx4/9rJghbTOLCvfVsXYxcHEICRxgl 1j/bDuUsZ5To2N/LCFLFJmAl0dG7hx0kISJwnlGi6cMPdpAEs4COxM5Z78DGCgsES+z6OhEs LiIQInH7wBQ2CNtKYtm7Y2CDWARUJWbdughm8wr4Sly/uY0JYlszo8TUa6tZQBKcQIlle5aB FTEC3ff91BomiGXiEreezIe6W0BiyZ7zzBC2qMTLx/+gflOW+D7nEdAcDqB6TYn1u/QhWhUl pnQ/ZIfYKyhxcuYTlgmMYrOQTJ2F0DELSccsJB0LGFlWMXKUFqeW5aYbGW5iBMbYMQk2xx2M Cz5ZHmKU5mBREuf98tY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjgYnmOq5T5505aLS2 yql/l8zd7TXPizIc9v2V9HaKdRE6+VX9TWNq2AsZGeNbrnktFc98c+69tPzOZVNizVK9Sk45 ZYtC+JHs9YdbzxsU9O8ztGr4Ueq98enPeaq9ei9+/k2y2fuKfUXGE/Fv3XySHLpCaYmLPJ0W JAS1zs5b9/H3DUH1mp9KLMUZiYZazEXFiQAuB7FWfwIAAA== 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: Sat, 11 Jan 2014 02:57:26 -0000 DQoNCkhlbGxvIEVyaWMgYW5kIEFuZHJldzoNCg0KVGhhbmsgeW91IGJvdGggdmVyeSBtdWNoIGZv ciBwcm92aWRpbmcgdGhlIGRldGFpbCBjb21tZW50cywgaGVscGZ1bCBzdWdnZXN0aW9ucyAgYW5k IGhlbHBpbmcgd2l0aCBjbGFyaWZ5aW5nIHRoZSBleGlzdGluZyBpc3N1ZXMgaW4gSVB2NiBORCB3 aXRoIG1vcmUgZGF0YS4NCg0KV2UsIHRoZSBjby1hdXRob3JzIGFyZSBnb2luZyB0byB3b3JrIHdp dGggdGhlIFdHIGNoYWlycyBpbiBsaWdodCBvZiB0aGUgY29tbWVudHMgd2UgZ2F0aGVyZWQgc28g ZmFyIGluIHRoZSBsaXN0IGFuZCBzdWJtaXQgaW1wcm92ZWQgdmVyc2lvbnMgaW4gbmV4dCBmZXcg d2Vla3MuDQoNCg0KVGhhbmtzIHRvIGFsbCB3aG8gcHJvdmlkZWQgY29tbWVudHMvaW5zaWdodHMs IHBvaW50ZWQgb3V0ICB0aGUgd2Vha25lc3NlcywgYW5kIHRvIHRob3NlIHdobyBzdXBwb3J0ZWQg dGhlIGRvY3VtZW50IHRvIGJlIGFkb3B0ZWQuDQoNCi1TYW1pdGEgDQo= From lorenzo@google.com Fri Jan 10 20:26: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 D4B441ADF86 for ; Fri, 10 Jan 2014 20:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.616 X-Spam-Level: X-Spam-Status: No, score=-1.616 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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.538, 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 xiuuchINmPMW for ; Fri, 10 Jan 2014 20:26:13 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 526D01AD10A for ; Fri, 10 Jan 2014 20:26:13 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id to1so1982802ieb.16 for ; Fri, 10 Jan 2014 20:26:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=p+1lm02LYTsIOrB1ZnEYfaSLGg9nHh9tfc0rjbQjhoo=; b=pr9iwX/XSWIvOwtUQ8Kk2fPQCGGckfb4v5H5GA4jTv1Tuy7zPutkPaMTNrL++hCIMu KirIQ3Hd7N6tmZ9wYLRCmdKvrvdVV1666R6uceyLKW/RdChboP4l4piLMuw2EWIQ8A2m e7bA5KnG9+6HpmpGU7qnEEILyzDTHUJpHiRti+Kzhg7/nlMc8NILj7UKK7oiW4cSJGP2 At7xmOwLuPrhGxNfZUa4sYUoiepxKPbi/xfwk221TFH+xj9+UcDCrpkrUQtGY+3d8T1o TK+0j/QdASthw1O5bX2B7Z0N5IEtdVgr0QWjz5xS1mphE80yUzqspHXdpfMn7w2Sd56w xtqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=p+1lm02LYTsIOrB1ZnEYfaSLGg9nHh9tfc0rjbQjhoo=; b=kIQSQFf777DwW4JRlqw2rgToX2xgEsdetj+JZ5QQdLZfPHYpF6/w861amSYHnSsgEN MF5BwI7nALgjO1mmsx6ffrZwfgpSU9bz0EhTITDGuQ3RCIYmH2qmkG2eFaQy27WKKDtK E+APgMAc/21vsWYJ8CGjxga5w8if6B7vvZUEPZG/eF6PY7RdLg6ZrOY08TYFX/8hBfyR D1PDNJ8IiB6xtFkIZUcKfhfIjScZDbbOMRq0zmWk4U8PmsrDXh14EolPArhZNtsRjz1y u5h9INJlZ7vSYSm+5/2f0ENC9XFfw3qp1hLmsjD8x3IG9B79F++IFo57lqiVl5TfSJtf Bwdw== X-Gm-Message-State: ALoCoQmuB9RC/H0RSlU3Hjc/TnK6ECs580y6nXE1aukxPAj/HozEtELOcXIFATvwUdtytt0374uxPOijADZBd74/vgWvbd0Wmj6/BPjMOps8UgN3pJyZ3rVV+B6/CtWaF5woFkfk34Yd7ZhpPVC5pqhM6HeagqLDXXUMWxM05RrSECj3GMrfufo3eNhnKrANbawYHZ2g0614 X-Received: by 10.43.150.18 with SMTP id km18mr11459886icc.43.1389414362982; Fri, 10 Jan 2014 20:26:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Fri, 10 Jan 2014 20:25:42 -0800 (PST) From: Lorenzo Colitti Date: Sat, 11 Jan 2014 13:25:42 +0900 Message-ID: Subject: Reducing the battery impact of ND To: =?UTF-8?Q?Andrew_=F0=9F=91=BD_Yourtchenko?= Content-Type: multipart/alternative; boundary=001a11c3000c8d525b04efaa3d93 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 11 Jan 2014 04:26:16 -0000 --001a11c3000c8d525b04efaa3d93 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Andrew, thank you for bringing solid data and analysis to the equation. That is always appreciated. On Sat, Jan 11, 2014 at 8:57 AM, Andrew =F0=9F=91=BD Yourtchenko wrote: > 2) The bigger problem - the battery life: > This can be a real problem, yes. But as you say, I think we can mitigate it well without changing ND at all. > WiFi is a pretty expensive thing to do, power-wise. To help extend the > battery, the mobile devices try very hard to shut off the radio > whenever they can. The wireless station would go to sleep, and inform > the AP about this fact - so the AP can buffer the frames for it [1]. > Further optimizations in this area were introduced by 802.11e (WMM-PS) > [2], where the frames destined to workstation could be transmitted > more efficiently and radio duty cycle is reduced. > > Spontaneous all-hosts multicasts interfere with these mechanisms, thus > the battery drain on the devices is much higher One thing that I think we haven't discussed here is that in principle, there are *very few* all-hosts multicasts - basically, only RA. Even RS is all-routers multicast, not all hosts. So really the only thing we're talking about is solicited-node multicasts for NS (and occasional unsolicited NAs, which should only really happen when nodes change their MAC addresses. Note that I'm not talking about malicious nodes here because any malicious node can decide to spam the link with multicast messages regardless of what the ND protocol looks like. I think that using multicast instead of broadcast and defining solicited-node multicast addresses based on the IID, were very wise choices. This is because there are so many different groups (2^24), that even in very large networks, each solicited-node multicast group will likely only have one member. So - at least in principle - there are two layers at which the battery impact of NS packets can be reduced to zero or close to zero: 1. If the AP keeps state of what MAC addresses have joined which multicast groups, it can selectively turn multicast NS into a set of unicast NS (L2 unicast; not L3 unicast). This will be a pretty significa= nt bandwidth optimization both because a) as you say, unicast is faster tha= n multicast, and b) because one multicast NS will almost certainly turn in= to only one unicast NS. Win/win. 2. Even if the AP does not do #1, if the wifi chipset in the device keeps state of what multicast groups the device has joined, then the wif= i chipset can simply drop packets that aren't interesting to the device's main CPU. From experience we know that this can also lead to massive battery savings - the wifi chipset is basically on a lot of the time anyway, because it has to listen for beacons and incoming packets, and t= his sort of filtering can be pretty efficient. That leaves RAs. Multicast RAs are a bane for battery life, because every time a device joins the network, it sends an RS. If the router responds with a multicast RA, then all devices on the link get a packet which they didn't need. On large wifi networks, I've seen this cause RAs once every 3-4 seconds, which is really painful in terms of battery life. Fortunately, there's an easy solution here: respond to router solicitations with unicast RAs sent to the sender. This is pretty trivial, and it doesn't require any state anywhere. There is a corner case where, if 10000 devices come online at the same time because the AP just booted up, you can get a thundering herd problem and have to send 10000 unicast packets, but this is can be optimized too: if the router sees that it's sending more than 100 solicited unicast RAs per second, it can simply send a multicast RA instead. > - especially in a typical network where the mobile devices move, and migh= t > trigger an RS/RA on each L2 roam between BSSIDs. > The client devices I'm familiar with don't send RSes when L2 roaming between BSSIDs on the same SSID. Is this a bug? Should they? I hear someone saying: "Yes, but this is all about wireless, DC is all > different story - it's all switches, they don't hold the state!" - yes > and no. I'd argue that it's not "yes and no", it's just "no". The state required by the approaches I suggest above is the same amount of state as multicast snooping, and it's pretty much the same amount of state required by the efficient ND approach - but it doesn't require complicating the ND protocol > Maybe worth to split the problem area into smaller subsets and see > whether a "cheaper" solutions are possible. Let's first take the > "multicast RAs" problem, and assume we do the below steps: > > a) Allow the environments that wish to do so, to send solicited RAs > unicast. (standard already permits to do so). > Yes please! > b) Have the hosts restart the Resilient RS [5] process at 1/2 or so > of router lifetime expiry: the router now can have the heuristic to > know which hosts are supporting the "unicast RA update" mechanism > *and* did not receive the periodic RA which would have been sent > usually at 1/3 the lifetime expiry (three RAs per lifetime rule of > thumb). > Yes please! > c) bump up the allowable MaxRtrAdvInterval and AdvDefaultLifetime to > their maximum theoretically possible values (spec says the hosts > should already be able to handle those, I did not test though) - this > would allow to further reduce the periodic RA frequency, from 2.5 > hours today to ~18.2 hours, or, if we feel adventurous, put all-ones > to be a "solicited-only RAs by default" - thus, unless another router > sends an RA with different lifetime, refreshing the router info > becomes host-driven, with an option for a router to override at any > time. > This sort of depends what device you have. For example - on a mobile phone, receiving one packet every 2.5 hours is *so far down* in the noise that it just doesn't matter. Your phone is doing a massive amount of stuff already - it's syncing your email, receiving wifi beacons, checking calendar alarms, etc. etc. All of that uses way more CPU than receiving one multicast RA. There may be other devices that have lower power requirements, though I'm not sure - perhaps these devices simply can't use 802.11-style wifi because it's too expensive, and so already have to use something like 6LowPAN. I don't know if there's a use case here. > These steps take care of the "multicast RA" problem. But again, also, > each of them by itself brings incremental usefulness, and is doable on > a single device =3D> no "chicken and egg", they gradually shrink the > issue - and are compatible with the existing tweaks that solve the > same problem (in a more layer-violating way). > Care to work together on a document that provides operational guidance to optimize battery impact of ND on wifi networks? Since they involve zero protocol changes, v6ops would be a good candidate group for it. And it might help persuade vendors that are not your employer to implement stuff like this :-) > Now let's think of updating the various caches while roaming: > How much more do you think this sort of thing will help, assuming we do the "100% feasible using the existing protocol" stuff above? NB: the above does not take care of the "defending the host's address > on behalf of the sleeping node" problem. > An NS is 72 bytes, and if we do multicast snooping, then a sleeping node is only ever going to be woken up if a node with the same last 3 address bytes shows up. That should be extremely rare. Cheers, Lorenzo --001a11c3000c8d525b04efaa3d93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Andr= ew,

th= ank you for bringing solid data and analysis to the equation. That is alway= s appreciated.

On Sat, Jan= 11, 2014 at 8:57 AM, Andrew =F0=9F=91=BD Yourtchenko &l= t;ayourtch@gmail.co= m> wrote:
2) The bigger problem - the battery life:

This can be a real problem, yes. But as you say, I thin= k we can mitigate it well without changing ND at all.
=C2=A0
WiFi is a pretty expensive thing to do, power-wise. To help extend the
battery, the mobile devices try very hard to shut off the radio
whenever they can. The wireless station would go to sleep, and inform
the AP about this fact - so the AP can buffer the frames for it [1].
Further optimizations in this area were introduced by 802.11e (WMM-PS)
[2], where the frames destined to workstation could be transmitted
more efficiently and radio duty cycle is reduced.

Spontaneous all-hosts multicasts interfere with these mechanisms, thus
the battery drain on the devices is much higher

=
One thing that I think we haven't discussed here is that in princi= ple, there are *very few* all-hosts multicasts - basically, only RA. Even R= S is all-routers multicast, not all hosts. So really the only thing we'= re talking about is solicited-node multicasts for NS (and occasional unsoli= cited NAs, which should only really happen when nodes change their MAC addr= esses. Note that I'm not talking about malicious nodes here because any= malicious node can decide to spam the link with multicast messages regardl= ess of what the ND protocol looks like.

I think that using multicast instead of broadcast and d= efining solicited-node multicast addresses based on the IID, were very wise= choices. This is because there are so many different groups (2^24), that e= ven in very large networks, each solicited-node multicast group will likely= only have one member. So - at least in principle - there are two layers at= which the battery impact of NS packets can be reduced to zero or close to = zero:
  1. If the AP keeps state of what MAC addresses have joined which = multicast groups, it can selectively turn multicast NS into a set of unicas= t NS (L2 unicast; not L3 unicast). This will be a pretty significant bandwi= dth optimization both because a) as you say, unicast is faster than multica= st, and b) because one multicast NS will almost certainly turn into only on= e unicast NS. Win/win.
  2. Even if the AP does not do #1, if the wifi chipset in the device k= eeps state of what multicast groups the device has joined, then the wifi ch= ipset can simply drop packets that aren't interesting to the device'= ;s main CPU. From experience we know that this can also lead to massive bat= tery savings - the wifi chipset is basically on a lot of the time anyway, b= ecause it has to listen for beacons and incoming packets, and this sort of = filtering can be pretty efficient.
That leaves RAs. Multicast RAs are a bane for battery = life, because every time a device joins the network, it sends an RS. If the= router responds with a multicast RA, then all devices on the link get a pa= cket which they didn't need. On large wifi networks, I've seen this= cause RAs once every 3-4 seconds, which is really painful in terms of batt= ery life. Fortunately, there's an easy solution here: respond to router= solicitations with unicast RAs sent to the sender. This is pretty trivial,= and it doesn't require any state anywhere. There is a corner case wher= e, if 10000 devices come online at the same time because the AP just booted= up, you can get a thundering herd problem and have to send 10000 unicast p= ackets, but this is can be optimized too: if the router sees that it's = sending more than 100 solicited unicast RAs per second, it can simply send = a multicast RA instead.
=C2=A0
- especially in a=C2=A0typical network w= here the mobile devices move, and might trigger an=C2=A0RS/RA on each L2 ro= am between BSSIDs.

The client devices I'm familiar with d= on't send RSes when L2 roaming between BSSIDs on the same SSID. Is this= a bug? Should they?

I hear someone saying: "Yes, but this is all about wireless, DC is all=
different story - it's all switches, they don't hold the state!&quo= t; - yes
and no.

I'd argue that it's not &qu= ot;yes and no", it's just "no". The state required by th= e approaches I suggest above is the same amount of state as multicast snoop= ing, and it's pretty much the same amount of state required by the effi= cient ND approach - but it doesn't require complicating the ND protocol=
=C2=A0
Maybe worth to split the problem area int= o smaller subsets and see
whether a "cheaper" solutions are possible. Let's first take = the
"multicast RAs" problem, and assume we do the below steps:

a) Allow the environments that wish to do so, to send solicited RAs
unicast. (standard already permits to do so).

Yes please!
=C2=A0
b) Have the hosts restart the =C2=A0Resilient RS [5] process at 1/2 or so of router lifetime expiry: the router now can have the heuristic to
know which hosts are supporting the "unicast RA update" mechanism=
*and* did not receive the periodic RA which would have been sent
usually at 1/3 the lifetime expiry (three RAs per lifetime rule of
thumb).

Yes please!
=C2=A0
c) bump up the allowable MaxRtrAdvInterval and AdvDefaultLifetime to
their maximum theoretically possible values (spec says the hosts
should already be able to handle those, I did not test though) - this
would allow to further reduce the periodic RA frequency, from 2.5
hours today to ~18.2 hours, or, if we feel adventurous, put all-ones
to be a "solicited-only RAs by default" - thus, unless another ro= uter
sends an RA with different lifetime, refreshing the router info
becomes host-driven, with an option for a router to override at any
time.

This sort of depends what device = you have. For example - on a mobile phone, receiving one packet every 2.5 h= ours is *so far down* in the noise that it just doesn't matter. Your ph= one is doing a massive amount of stuff already - it's syncing your emai= l, receiving wifi beacons, checking calendar alarms, etc. etc. All of that = uses way more CPU than receiving one multicast RA.

There may be other devices that have lower power requir= ements, though I'm not sure - perhaps these devices simply can't us= e 802.11-style wifi because it's too expensive, and so already have to = use something like 6LowPAN. I don't know if there's a use case here= .
=C2=A0
These steps take care of the "multic= ast RA" problem. But again, also,
each of them by itself brings incremental usefulness, and is doable on
a single device =3D> no "chicken and egg", they gradually shri= nk the
issue - and are compatible with the existing tweaks that solve the
same problem (in a more layer-violating way).

Care to work together on a document that provides operational guidan= ce to optimize battery impact of ND on wifi networks? Since they involve ze= ro protocol changes, v6ops would be a good candidate group for it. And it m= ight help persuade vendors that are not your employer to implement stuff li= ke this :-)
=C2=A0
Now let's think of updating the vario= us caches while roaming:

How much more do you think this sort of th= ing will help, assuming we do the "100% feasible using the existing pr= otocol" stuff above?

NB: the above does not take care of the "defending the host's addr= ess
on behalf of the sleeping node" problem.

An NS is 72 bytes, and if we do multicast snooping, then a sleeping = node is only ever going to be woken up if a node with the same last 3 addre= ss bytes shows up. That should be extremely rare.

Cheers,
Lorenzo
--001a11c3000c8d525b04efaa3d93-- From v6ops@globis.net Sat Jan 11 06:25: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 187F51ADFBA for ; Sat, 11 Jan 2014 06:25:43 -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 XGFncpRjo66l for ; Sat, 11 Jan 2014 06:25:42 -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 9E2EB1ADF87 for ; Sat, 11 Jan 2014 06:25:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id DE8788714A2; Sat, 11 Jan 2014 15:25:30 +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 diEJ7L685khe; Sat, 11 Jan 2014 15:25:30 +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 C1285870089; Sat, 11 Jan 2014 15:25:30 +0100 (CET) Message-ID: <52D15486.1030705@globis.net> Date: Sat, 11 Jan 2014 15:26:14 +0100 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: Zillions of addresses [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] References: <52C9D788.8060606@gmail.com> <52CBE0E6.5020107@globis.net> <52CECC76.1030706@globis.net> <52CFAB11.4070404@globis.net> <52D073CC.6070205@gmail.com> In-Reply-To: <52D073CC.6070205@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: Sat, 11 Jan 2014 14:25:43 -0000 > Brian E Carpenter > 10 January 2014 23:27 >> But problems in their /48 with a rogue node assigning zillions of addresses and creating zillions of sessions should not spill over into the rest of the network managed by others. > > Who says that is a rogue node? It sounds like perfectly legitimate > behaviour for a virtual machine environment that is designed to > virtualise at layer 3. If you want those VM addresses to be > unguessable for an off-path attacker, you might well spread them > sparsely across a /64. > > Anyway -- I am not seeing much in this thread that suggests text changes > in the -why64 draft (which is intended to be factual). I take Ray's > original point that there *might* be other risks than ND exhaustion, > and we'll add that to the next version. > > Regards > Brian > > Agreed. I would also like to reiterate a basic requirement from network and system operators, and propose the following text for -why64. / There is a desire by many network operators to 1) know and audit which nodes are active on a network (perhaps by carrying out exhaustive scanning of address space that is allowed to communicate off link) 2) be able to limit the total number of active addresses and sessions that can be sourced from a particular host, LAN or site, in order to prevent potential resource depletion attacks or other problems spreading beyond a certain scope of control. One way of limiting the scan space, or limiting the number of possible source addresses and sessions from a LAN, is to increase the prefix length >> 64. This may currently break many widely-deployed solutions, such as SLAAC. There are alternatives, which present a different set of trade offs e.g. with respect to the right of privacy of the end user versus the rights of the operator to control and protect their network. / Whether you think the solution of extending prefix length >>64 is good or not is a separate debate. IMHO Technically it should be possible. CIDR has NOT been deprecated. I think imposing a hard limit of /64 is harmful, as it limits operators choice of operations model and protocols e.g. flow-based WFQ becomes vulnerable to trivial attacks from a single node, whereas there's nothing fundamentally wrong with flow-based WFQ technology per se, or indeed other mechanisms that require tracking state to /128. e..g exhaustive network scanning to check for vulnerable open ports on unpatched machines becomes impractical, whereas there's nothing fundamentally wrong with the concept in an enterprise environment. Lorenzo and I clearly disagree on this point, but I see no value in continuing the debate on list wrt this draft. it took long enough to get to the current status on allowing use of /127 instead of /64 for point to point links (3627, 6164, 6547) -- Regards, RayH From tjc@ecs.soton.ac.uk Sat Jan 11 09:23: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 315371ADF46 for ; Sat, 11 Jan 2014 09:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.758 X-Spam-Level: X-Spam-Status: No, score=-1.758 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.538, SPF_NEUTRAL=0.779] 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 dYR6Fic9Qnzx for ; Sat, 11 Jan 2014 09:23:35 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id C4B701ADF4D for ; Sat, 11 Jan 2014 09:23:34 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s0BHNHNn004491; Sat, 11 Jan 2014 17:23:17 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s0BHNHNn004491 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1389460998; bh=hpCIMWZqTKlFOfryNyV2jgibbmI=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=CrQ+Ta3ipB8vIJ3HJOr3Th0JysdFNuEnNYJxrr6Df/S2hjZqaoRrRAOHLCAUw2hd6 4mNxO8cG/JbUmkO7w7zjwa8VY1ivcnmcwh4v0Dd5gMhQuD1KLKhRJx2uiK5PcTj3zr 7In71lGF2nKtrj4jghIHLAMWYg52qxlkMxPNUhOk= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q0AHNH09596091428y ret-id none; Sat, 11 Jan 2014 17:23:18 +0000 Received: from [192.168.1.101] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s0BHLtYx030156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 11 Jan 2014 17:21:56 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_C151AAED-1429-4AD4-A0D2-0B5A6B4F8A36" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Reducing the battery impact of ND From: Tim Chown In-Reply-To: Date: Sat, 11 Jan 2014 17:21:52 +0000 Message-ID: References: To: Lorenzo Colitti X-Mailer: Apple Mail (2.1827) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q0AHNH095960914200; tid=q0AHNH09596091428y; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s0BHNHNn004491 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG , =?utf-8?Q?Andrew_=F0=9F=91=BD_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: Sat, 11 Jan 2014 17:23:39 -0000 --Apple-Mail=_C151AAED-1429-4AD4-A0D2-0B5A6B4F8A36 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, On 11 Jan 2014, at 04:25, Lorenzo Colitti wrote: > Andrew, >=20 > thank you for bringing solid data and analysis to the equation. That = is always appreciated. >=20 > On Sat, Jan 11, 2014 at 8:57 AM, Andrew =F0=9F=91=BD Yourtchenko = wrote: > 2) The bigger problem - the battery life: >=20 > This can be a real problem, yes. But as you say, I think we can = mitigate it well without changing ND at all. > =20 > WiFi is a pretty expensive thing to do, power-wise. To help extend the > battery, the mobile devices try very hard to shut off the radio > whenever they can. The wireless station would go to sleep, and inform > the AP about this fact - so the AP can buffer the frames for it [1]. > Further optimizations in this area were introduced by 802.11e (WMM-PS) > [2], where the frames destined to workstation could be transmitted > more efficiently and radio duty cycle is reduced. >=20 > Spontaneous all-hosts multicasts interfere with these mechanisms, thus > the battery drain on the devices is much higher >=20 > One thing that I think we haven't discussed here is that in principle, = there are *very few* all-hosts multicasts - basically, only RA. Even RS = is all-routers multicast, not all hosts. So really the only thing we're = talking about is solicited-node multicasts for NS (and occasional = unsolicited NAs, which should only really happen when nodes change their = MAC addresses. Note that I'm not talking about malicious nodes here = because any malicious node can decide to spam the link with multicast = messages regardless of what the ND protocol looks like. This is a useful reminder to consider the use/impact of multicast in the = dnssd work, given one of the scenarios is Zigbee networks. mDNS uses = ff02::fb iirc. Tim > I think that using multicast instead of broadcast and defining = solicited-node multicast addresses based on the IID, were very wise = choices. This is because there are so many different groups (2^24), that = even in very large networks, each solicited-node multicast group will = likely only have one member. So - at least in principle - there are two = layers at which the battery impact of NS packets can be reduced to zero = or close to zero: > If the AP keeps state of what MAC addresses have joined which = multicast groups, it can selectively turn multicast NS into a set of = unicast NS (L2 unicast; not L3 unicast). This will be a pretty = significant bandwidth optimization both because a) as you say, unicast = is faster than multicast, and b) because one multicast NS will almost = certainly turn into only one unicast NS. Win/win. > Even if the AP does not do #1, if the wifi chipset in the device keeps = state of what multicast groups the device has joined, then the wifi = chipset can simply drop packets that aren't interesting to the device's = main CPU. =46rom experience we know that this can also lead to massive = battery savings - the wifi chipset is basically on a lot of the time = anyway, because it has to listen for beacons and incoming packets, and = this sort of filtering can be pretty efficient. > That leaves RAs. Multicast RAs are a bane for battery life, because = every time a device joins the network, it sends an RS. If the router = responds with a multicast RA, then all devices on the link get a packet = which they didn't need. On large wifi networks, I've seen this cause RAs = once every 3-4 seconds, which is really painful in terms of battery = life. Fortunately, there's an easy solution here: respond to router = solicitations with unicast RAs sent to the sender. This is pretty = trivial, and it doesn't require any state anywhere. There is a corner = case where, if 10000 devices come online at the same time because the AP = just booted up, you can get a thundering herd problem and have to send = 10000 unicast packets, but this is can be optimized too: if the router = sees that it's sending more than 100 solicited unicast RAs per second, = it can simply send a multicast RA instead. > =20 > - especially in a typical network where the mobile devices move, and = might trigger an RS/RA on each L2 roam between BSSIDs. >=20 > The client devices I'm familiar with don't send RSes when L2 roaming = between BSSIDs on the same SSID. Is this a bug? Should they? >=20 > I hear someone saying: "Yes, but this is all about wireless, DC is all > different story - it's all switches, they don't hold the state!" - yes > and no. >=20 > I'd argue that it's not "yes and no", it's just "no". The state = required by the approaches I suggest above is the same amount of state = as multicast snooping, and it's pretty much the same amount of state = required by the efficient ND approach - but it doesn't require = complicating the ND protocol > =20 > Maybe worth to split the problem area into smaller subsets and see > whether a "cheaper" solutions are possible. Let's first take the > "multicast RAs" problem, and assume we do the below steps: >=20 > a) Allow the environments that wish to do so, to send solicited RAs > unicast. (standard already permits to do so). >=20 > Yes please! > =20 > b) Have the hosts restart the Resilient RS [5] process at 1/2 or so > of router lifetime expiry: the router now can have the heuristic to > know which hosts are supporting the "unicast RA update" mechanism > *and* did not receive the periodic RA which would have been sent > usually at 1/3 the lifetime expiry (three RAs per lifetime rule of > thumb). >=20 > Yes please! > =20 > c) bump up the allowable MaxRtrAdvInterval and AdvDefaultLifetime to > their maximum theoretically possible values (spec says the hosts > should already be able to handle those, I did not test though) - this > would allow to further reduce the periodic RA frequency, from 2.5 > hours today to ~18.2 hours, or, if we feel adventurous, put all-ones > to be a "solicited-only RAs by default" - thus, unless another router > sends an RA with different lifetime, refreshing the router info > becomes host-driven, with an option for a router to override at any > time. >=20 > This sort of depends what device you have. For example - on a mobile = phone, receiving one packet every 2.5 hours is *so far down* in the = noise that it just doesn't matter. Your phone is doing a massive amount = of stuff already - it's syncing your email, receiving wifi beacons, = checking calendar alarms, etc. etc. All of that uses way more CPU than = receiving one multicast RA. >=20 > There may be other devices that have lower power requirements, though = I'm not sure - perhaps these devices simply can't use 802.11-style wifi = because it's too expensive, and so already have to use something like = 6LowPAN. I don't know if there's a use case here. > =20 > These steps take care of the "multicast RA" problem. But again, also, > each of them by itself brings incremental usefulness, and is doable on > a single device =3D> no "chicken and egg", they gradually shrink the > issue - and are compatible with the existing tweaks that solve the > same problem (in a more layer-violating way). >=20 > Care to work together on a document that provides operational guidance = to optimize battery impact of ND on wifi networks? Since they involve = zero protocol changes, v6ops would be a good candidate group for it. And = it might help persuade vendors that are not your employer to implement = stuff like this :-) > =20 > Now let's think of updating the various caches while roaming: >=20 > How much more do you think this sort of thing will help, assuming we = do the "100% feasible using the existing protocol" stuff above? >=20 > NB: the above does not take care of the "defending the host's address > on behalf of the sleeping node" problem. >=20 > An NS is 72 bytes, and if we do multicast snooping, then a sleeping = node is only ever going to be woken up if a node with the same last 3 = address bytes shows up. That should be extremely rare. >=20 > Cheers, > Lorenzo > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_C151AAED-1429-4AD4-A0D2-0B5A6B4F8A36 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

On 11 Jan 2014, at 04:25, = Lorenzo Colitti <lorenzo@google.com> = wrote:

Andrew,

thank you for = bringing solid data and analysis to the equation. That is always = appreciated.

On Sat, = Jan 11, 2014 at 8:57 AM, Andrew =F0=9F=91=BD Yourtchenko <ayourtch@gmail.com> wrote:
2) The bigger problem - the battery = life:

This can be a real problem, yes. But as you say, I = think we can mitigate it well without changing ND at = all.
 
WiFi is a pretty expensive thing to do, power-wise. To help extend = the
battery, the mobile devices try very hard to shut off the radio
whenever they can. The wireless station would go to sleep, and = inform
the AP about this fact - so the AP can buffer the frames for it [1].
Further optimizations in this area were introduced by 802.11e = (WMM-PS)
[2], where the frames destined to workstation could be transmitted
more efficiently and radio duty cycle is reduced.

Spontaneous all-hosts multicasts interfere with these mechanisms, = thus
the battery drain on the devices is much = higher

One thing that I think we haven't = discussed here is that in principle, there are *very few* all-hosts = multicasts - basically, only RA. Even RS is all-routers multicast, not = all hosts. So really the only thing we're talking about is = solicited-node multicasts for NS (and occasional unsolicited NAs, which = should only really happen when nodes change their MAC addresses. Note = that I'm not talking about malicious nodes here because any malicious = node can decide to spam the link with multicast messages regardless of = what the ND protocol looks = like.

This is a = useful reminder to consider the use/impact of multicast in the dnssd = work, given one of the scenarios is Zigbee networks. mDNS uses ff02::fb = iirc.

Tim

I think that using multicast instead of broadcast and defining = solicited-node multicast addresses based on the IID, were very wise = choices. This is because there are so many different groups (2^24), that = even in very large networks, each solicited-node multicast group will = likely only have one member. So - at least in principle - there are two = layers at which the battery impact of NS packets can be reduced to zero = or close to zero:
  1. If the AP keeps state of what MAC addresses have joined = which multicast groups, it can selectively turn multicast NS into a set = of unicast NS (L2 unicast; not L3 unicast). This will be a pretty = significant bandwidth optimization both because a) as you say, unicast = is faster than multicast, and b) because one multicast NS will almost = certainly turn into only one unicast NS. Win/win.
  2. Even if the AP does not do #1, if the wifi chipset in the = device keeps state of what multicast groups the device has joined, then = the wifi chipset can simply drop packets that aren't interesting to the = device's main CPU. =46rom experience we know that this can also lead to = massive battery savings - the wifi chipset is basically on a lot of the = time anyway, because it has to listen for beacons and incoming packets, = and this sort of filtering can be pretty efficient.
That leaves RAs. Multicast RAs are a bane for = battery life, because every time a device joins the network, it sends an = RS. If the router responds with a multicast RA, then all devices on the = link get a packet which they didn't need. On large wifi networks, I've = seen this cause RAs once every 3-4 seconds, which is really painful in = terms of battery life. Fortunately, there's an easy solution here: = respond to router solicitations with unicast RAs sent to the sender. = This is pretty trivial, and it doesn't require any state anywhere. There = is a corner case where, if 10000 devices come online at the same time = because the AP just booted up, you can get a thundering herd problem and = have to send 10000 unicast packets, but this is can be optimized too: if = the router sees that it's sending more than 100 solicited unicast RAs = per second, it can simply send a multicast RA instead.
 
- especially in a typical network = where the mobile devices move, and might trigger an RS/RA on each = L2 roam between BSSIDs.

The client devices I'm familiar with = don't send RSes when L2 roaming between BSSIDs on the same SSID. Is this = a bug? Should they?

I hear someone saying: "Yes, but this is all about wireless, DC is = all
different story - it's all switches, they don't hold the state!" - = yes
and no.

I'd argue that it's not "yes and = no", it's just "no". The state required by the approaches I suggest = above is the same amount of state as multicast snooping, and it's pretty = much the same amount of state required by the efficient ND approach - = but it doesn't require complicating the ND protocol
 
Maybe worth to split the problem area = into smaller subsets and see
whether a "cheaper" solutions are possible. Let's first take the
"multicast RAs" problem, and assume we do the below steps:

a) Allow the environments that wish to do so, to send solicited RAs
unicast. (standard already permits to do = so).

Yes = please!
 
b) Have the hosts restart the  Resilient RS [5] process at 1/2 or = so
of router lifetime expiry: the router now can have the heuristic to
know which hosts are supporting the "unicast RA update" mechanism
*and* did not receive the periodic RA which would have been sent
usually at 1/3 the lifetime expiry (three RAs per lifetime rule of
thumb).

Yes = please!
 
c) bump up the allowable MaxRtrAdvInterval and AdvDefaultLifetime to
their maximum theoretically possible values (spec says the hosts
should already be able to handle those, I did not test though) - = this
would allow to further reduce the periodic RA frequency, from 2.5
hours today to ~18.2 hours, or, if we feel adventurous, put all-ones
to be a "solicited-only RAs by default" - thus, unless another = router
sends an RA with different lifetime, refreshing the router info
becomes host-driven, with an option for a router to override at any
time.

This sort of depends what = device you have. For example - on a mobile phone, receiving one packet = every 2.5 hours is *so far down* in the noise that it just doesn't = matter. Your phone is doing a massive amount of stuff already - it's = syncing your email, receiving wifi beacons, checking calendar alarms, = etc. etc. All of that uses way more CPU than receiving one multicast = RA.

There may be other devices that have lower power = requirements, though I'm not sure - perhaps these devices simply can't = use 802.11-style wifi because it's too expensive, and so already have to = use something like 6LowPAN. I don't know if there's a use case = here.
 
These steps take care of the "multicast = RA" problem. But again, also,
each of them by itself brings incremental usefulness, and is doable = on
a single device =3D> no "chicken and egg", they gradually shrink = the
issue - and are compatible with the existing tweaks that solve the
same problem (in a more layer-violating = way).

Care to work together on a = document that provides operational guidance to optimize battery impact = of ND on wifi networks? Since they involve zero protocol changes, v6ops = would be a good candidate group for it. And it might help persuade = vendors that are not your employer to implement stuff like this = :-)
 
Now let's think of updating the various = caches while roaming:

How much more do you think this sort of = thing will help, assuming we do the "100% feasible using the existing = protocol" stuff above?

NB: the above does not take care of the "defending the host's = address
on behalf of the sleeping node" = problem.

An NS is 72 bytes, and if = we do multicast snooping, then a sleeping node is only ever going to be = woken up if a node with the same last 3 address bytes shows up. That = should be extremely rare.

Cheers,
Lorenzo
= --------------------------------------------------------------------
IE= TF IPv6 working group mailing list
ipv6@ietf.org
Administrative = Requests: = https://www.ietf.org/mailman/listinfo/ipv6
----------------------------= ----------------------------------------

<= /body>= --Apple-Mail=_C151AAED-1429-4AD4-A0D2-0B5A6B4F8A36-- From tjc@ecs.soton.ac.uk Sat Jan 11 09:31: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 867111AE0B0 for ; Sat, 11 Jan 2014 09:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 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.538, SPF_NEUTRAL=0.779] 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 FoKlistOiHrs for ; Sat, 11 Jan 2014 09:31:23 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 55DFC1AE0AB for ; Sat, 11 Jan 2014 09:31:23 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s0BHV5HV006726; Sat, 11 Jan 2014 17:31:05 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s0BHV5HV006726 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1389461465; bh=GRiGSrNYRTXfb3kgGNsRwNekWqI=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=CIR5JpoSlyvENNc+hfizntagHwr32TMmIQeY1E+ACma8cOjLh8JBiwSXZ6qLH6FYg Jm5q9n2Rvb/awZJOFusnae35K7qbdME4Qk7pOLDcdwtDB/ICjR0hKaVAxS2KVem+0f 3Sf5f5S4YUW0Lvzucj1mLwsx4YxKZdI8vjfYRcf4= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id q0AHV50959609169o0 ret-id none; Sat, 11 Jan 2014 17:31:05 +0000 Received: from [192.168.1.101] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s0BHTiBF031710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 11 Jan 2014 17:29:45 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Zillions of addresses [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] From: Tim Chown In-Reply-To: <52D15486.1030705@globis.net> Date: Sat, 11 Jan 2014 17:29:44 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <52C9D788.8060606@gmail.com> <52CBE0E6.5020107@globis.net> <52CECC76.1030706@globis.net> <52CFAB11.4070404@globis.net> <52D073CC.6070205@gmail.com> <52D15486.1030705@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1827) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q0AHV5095960916900; tid=q0AHV50959609169o0; client=relay,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s0BHV5HV006726 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk 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: Sat, 11 Jan 2014 17:31:26 -0000 Hi, On 11 Jan 2014, at 14:26, Ray Hunter wrote: >> Brian E Carpenter >> 10 January 2014 23:27 >>> But problems in their /48 with a rogue node assigning zillions of = addresses and creating zillions of sessions should not spill over into = the rest of the network managed by others. >>=20 >> Who says that is a rogue node? It sounds like perfectly legitimate >> behaviour for a virtual machine environment that is designed to >> virtualise at layer 3. If you want those VM addresses to be >> unguessable for an off-path attacker, you might well spread them >> sparsely across a /64. >>=20 >> Anyway -- I am not seeing much in this thread that suggests text = changes >> in the -why64 draft (which is intended to be factual). I take Ray's >> original point that there *might* be other risks than ND exhaustion, >> and we'll add that to the next version. >>=20 >> Regards >> Brian >>=20 >>=20 > Agreed. >=20 > I would also like to reiterate a basic requirement from network and = system operators, and propose the following text for -why64. >=20 >=20 > / > There is a desire by many network operators to Many, or some? > 1) know and audit which nodes are active on a network (perhaps by = carrying out exhaustive scanning of address space that is allowed to = communicate off link) Or polling the network devices via SNMP or similar. Exhaustive scanning = of v6 space=85no. > 2) be able to limit the total number of active addresses and sessions = that can be sourced from a particular host, LAN or site, in order to = prevent potential resource depletion attacks or other problems spreading = beyond a certain scope of control. Documenting some examples of this would be useful. ND cache is one, = which I think is already mentioned. > One way of limiting the scan space, or limiting the number of possible = source addresses and sessions from a LAN, is to increase the prefix = length >> 64. Which is what makes this relevant to =91why64=92. > This may currently break many widely-deployed solutions, such as = SLAAC. Well, =91This will cause significant issues for the operation of the = network, as described elsewhere in this document=92 > There are alternatives, which present a different set of trade offs = e.g. with respect to the right of privacy of the end user versus the = rights of the operator to control and protect their network. > / Those alternatives are more likely to be viable in a tightly managed = environment, where there is administrative control of all devices, e.g. = so provacy addresses can be disabled by policy. Tim >=20 > Whether you think the solution of extending prefix length >>64 is good = or not is a separate debate. > IMHO Technically it should be possible. CIDR has NOT been deprecated. >=20 > I think imposing a hard limit of /64 is harmful, as it limits = operators choice of operations model and protocols > e.g. flow-based WFQ becomes vulnerable to trivial attacks from a = single node, whereas there's nothing fundamentally wrong with flow-based = WFQ technology per se, or indeed other mechanisms that require tracking = state to /128. > e..g exhaustive network scanning to check for vulnerable open ports on = unpatched machines becomes impractical, whereas there's nothing = fundamentally wrong with the concept in an enterprise environment. >=20 > Lorenzo and I clearly disagree on this point, but I see no value in = continuing the debate on list wrt this draft. > it took long enough to get to the current status on allowing use of = /127 instead of /64 for point to point links (3627, 6164, 6547) >=20 > --=20 > Regards, > RayH >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From d.sturek@att.net Sat Jan 11 09:37: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 53C231AE0AB for ; Sat, 11 Jan 2014 09:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, MIME_QP_LONG_LINE=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 n_oToz1KsDy4 for ; Sat, 11 Jan 2014 09:36:59 -0800 (PST) Received: from nm12-vm4.access.bullet.mail.gq1.yahoo.com (nm12-vm4.access.bullet.mail.gq1.yahoo.com [216.39.63.100]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF4F1AE017 for ; Sat, 11 Jan 2014 09:36:59 -0800 (PST) Received: from [216.39.60.172] by nm12.access.bullet.mail.gq1.yahoo.com with NNFMP; 11 Jan 2014 17:36:48 -0000 Received: from [67.195.22.118] by tm8.access.bullet.mail.gq1.yahoo.com with NNFMP; 11 Jan 2014 17:36:48 -0000 Received: from [127.0.0.1] by smtp113.sbc.mail.gq1.yahoo.com with NNFMP; 11 Jan 2014 17:36:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1389461808; bh=Ivr1XgNzN2FX69skXRtZeHKc2Hq/n4sgkVLkWVdexDk=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:References:In-Reply-To:Mime-version:Content-type; b=Gs2wlVJN0TPxs/e+Ov/hoZ5giqi92DO0NY8oP8LA6rg0v5chXPI29j42kaS4w/eknRdrBD/62WXxZTVQWt/YV0MPTRGaLmxX72IZtOhnMQnLGTstb3uW669o8gsU1XibpBvzdXJJQzCo6Vnadl3nVNukvbxSqmEElMwaYujQn5s= X-Yahoo-Newman-Id: 844331.98719.bm@smtp113.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 3GI4HfcVM1kv0Z7BBKSmPv0J.FfCyPi9JW6uF8RZTEBCcJz r1x73mAW1apT1HQTBnJQ8kRCrpoktPNe2dP3c4vUmXTHB6OO9Ipck8H2jdBY Op9565xAdW_9Ju0c.3pU7ebF1JHWgXTC4Bx05OKx4J89S0TCkDa3WPW5PlNA HEQw6J_m5.0kT_njz00G_BrWBYrrB_SaZ.X2UH5t1pWbLnzqyj6.4g1iJJhY .EvPskPFCvlhMPC3nyJa99OdToQTNuxzFZBlICVxocc.l3Er2cMU_W.y9iv7 eNUk6blOt3T7jy3wgjukecii7uauZf6f4v_Qy.Z30PQeznHIndxDu9FOgFga _yusAHbiokf5.fn3PFAWEVOGBGoACwxYKsTlr5WdbMubiYYPU5kuf0CYU2N4 i5gOVHzSB3IAO17KJ7MDV.1kJVXmBouLkeLy_LQxtlFjf6rHtwMaHrLNQaYH OYyRWdBRbbs2EucaveN3u5KRefkHrqFusszMGlXYR46EcBpS3o.r89lm3jCL oRGX9h3.I5oMI0aHSqySgj6eCUY2nae0myjk6rU1LU1Vc.EhYMt0BxdBl1Q- - X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.5] (d.sturek@69.106.87.113 with plain [67.195.15.5]) by smtp113.sbc.mail.gq1.yahoo.com with SMTP; 11 Jan 2014 09:36:48 -0800 PST User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Sat, 11 Jan 2014 09:36:42 -0800 Subject: Re: Reducing the battery impact of ND From: Don Sturek To: Tim Chown , Lorenzo Colitti Message-ID: Thread-Topic: Reducing the battery impact of ND References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3472277807_552699" Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Andrew =?UTF-8?B?8J+RvQ==?= 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, 11 Jan 2014 17:37:02 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3472277807_552699 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Tim, For the ZigBee networks, we had to extend mDNS (a now expired draft called Extended mDNS) since with a ROLL RPL mesh, each hop is defined as a link (s= o there was no way to use ff02::fb and reach all devices in a single ROLL RPL instance, or an attached subnet of Wi-Fi/HomePlug/etc. devices in a single residence). I hope dnssd takes up this topic and come up with a more complete standard that covers multi-hop subnets. Don From: Tim Chown Date: Saturday, January 11, 2014 9:21 AM To: Lorenzo Colitti Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG , Andrew =F0=9F=91=BD Yourtchenko Subject: Re: Reducing the battery impact of ND Hi, On 11 Jan 2014, at 04:25, Lorenzo Colitti wrote: > Andrew, >=20 > thank you for bringing solid data and analysis to the equation. That is a= lways > appreciated. >=20 > On Sat, Jan 11, 2014 at 8:57 AM, Andrew =F0=9F=91=BD Yourtchenko > wrote: >> 2) The bigger problem - the battery life: >=20 > This can be a real problem, yes. But as you say, I think we can mitigate = it > well without changing ND at all. > =20 >> WiFi is a pretty expensive thing to do, power-wise. To help extend the >> battery, the mobile devices try very hard to shut off the radio >> whenever they can. The wireless station would go to sleep, and inform >> the AP about this fact - so the AP can buffer the frames for it [1]. >> Further optimizations in this area were introduced by 802.11e (WMM-PS) >> [2], where the frames destined to workstation could be transmitted >> more efficiently and radio duty cycle is reduced. >>=20 >> Spontaneous all-hosts multicasts interfere with these mechanisms, thus >> the battery drain on the devices is much higher >=20 > One thing that I think we haven't discussed here is that in principle, th= ere > are *very few* all-hosts multicasts - basically, only RA. Even RS is > all-routers multicast, not all hosts. So really the only thing we're talk= ing > about is solicited-node multicasts for NS (and occasional unsolicited NAs= , > which should only really happen when nodes change their MAC addresses. No= te > that I'm not talking about malicious nodes here because any malicious nod= e can > decide to spam the link with multicast messages regardless of what the ND > protocol looks like. This is a useful reminder to consider the use/impact of multicast in the dnssd work, given one of the scenarios is Zigbee networks. mDNS uses ff02::fb iirc. Tim > I think that using multicast instead of broadcast and defining solicited-= node > multicast addresses based on the IID, were very wise choices. This is bec= ause > there are so many different groups (2^24), that even in very large networ= ks, > each solicited-node multicast group will likely only have one member. So = - at > least in principle - there are two layers at which the battery impact of = NS > packets can be reduced to zero or close to zero: > 1. If the AP keeps state of what MAC addresses have joined which multicas= t > groups, it can selectively turn multicast NS into a set of unicast NS (L2 > unicast; not L3 unicast). This will be a pretty significant bandwidth > optimization both because a) as you say, unicast is faster than multicast= , and > b) because one multicast NS will almost certainly turn into only one unic= ast > NS. Win/win. > 2.=20 > 3. Even if the AP does not do #1, if the wifi chipset in the device keeps > state of what multicast groups the device has joined, then the wifi chips= et > can simply drop packets that aren't interesting to the device's main CPU.= From > experience we know that this can also lead to massive battery savings - t= he > wifi chipset is basically on a lot of the time anyway, because it has to > listen for beacons and incoming packets, and this sort of filtering can b= e > pretty efficient. > That leaves RAs. Multicast RAs are a bane for battery life, because every= time > a device joins the network, it sends an RS. If the router responds with a > multicast RA, then all devices on the link get a packet which they didn't > need. On large wifi networks, I've seen this cause RAs once every 3-4 sec= onds, > which is really painful in terms of battery life. Fortunately, there's an= easy > solution here: respond to router solicitations with unicast RAs sent to t= he > sender. This is pretty trivial, and it doesn't require any state anywhere= . > There is a corner case where, if 10000 devices come online at the same ti= me > because the AP just booted up, you can get a thundering herd problem and = have > to send 10000 unicast packets, but this is can be optimized too: if the r= outer > sees that it's sending more than 100 solicited unicast RAs per second, it= can > simply send a multicast RA instead. > =20 >> - especially in a typical network where the mobile devices move, and mi= ght >> trigger an RS/RA on each L2 roam between BSSIDs. >=20 > The client devices I'm familiar with don't send RSes when L2 roaming betw= een > BSSIDs on the same SSID. Is this a bug? Should they? >=20 >> I hear someone saying: "Yes, but this is all about wireless, DC is all >> different story - it's all switches, they don't hold the state!" - yes >> and no. >=20 > I'd argue that it's not "yes and no", it's just "no". The state required = by > the approaches I suggest above is the same amount of state as multicast > snooping, and it's pretty much the same amount of state required by the > efficient ND approach - but it doesn't require complicating the ND protoc= ol > =20 >> Maybe worth to split the problem area into smaller subsets and see >> whether a "cheaper" solutions are possible. Let's first take the >> "multicast RAs" problem, and assume we do the below steps: >>=20 >> a) Allow the environments that wish to do so, to send solicited RAs >> unicast. (standard already permits to do so). >=20 > Yes please! > =20 >> b) Have the hosts restart the Resilient RS [5] process at 1/2 or so >> of router lifetime expiry: the router now can have the heuristic to >> know which hosts are supporting the "unicast RA update" mechanism >> *and* did not receive the periodic RA which would have been sent >> usually at 1/3 the lifetime expiry (three RAs per lifetime rule of >> thumb). >=20 > Yes please! > =20 >> c) bump up the allowable MaxRtrAdvInterval and AdvDefaultLifetime to >> their maximum theoretically possible values (spec says the hosts >> should already be able to handle those, I did not test though) - this >> would allow to further reduce the periodic RA frequency, from 2.5 >> hours today to ~18.2 hours, or, if we feel adventurous, put all-ones >> to be a "solicited-only RAs by default" - thus, unless another router >> sends an RA with different lifetime, refreshing the router info >> becomes host-driven, with an option for a router to override at any >> time. >=20 > This sort of depends what device you have. For example - on a mobile phon= e, > receiving one packet every 2.5 hours is *so far down* in the noise that i= t > just doesn't matter. Your phone is doing a massive amount of stuff alread= y - > it's syncing your email, receiving wifi beacons, checking calendar alarms= , > etc. etc. All of that uses way more CPU than receiving one multicast RA. >=20 > There may be other devices that have lower power requirements, though I'm= not > sure - perhaps these devices simply can't use 802.11-style wifi because i= t's > too expensive, and so already have to use something like 6LowPAN. I don't= know > if there's a use case here. > =20 >> These steps take care of the "multicast RA" problem. But again, also, >> each of them by itself brings incremental usefulness, and is doable on >> a single device =3D> no "chicken and egg", they gradually shrink the >> issue - and are compatible with the existing tweaks that solve the >> same problem (in a more layer-violating way). >=20 > Care to work together on a document that provides operational guidance to > optimize battery impact of ND on wifi networks? Since they involve zero > protocol changes, v6ops would be a good candidate group for it. And it mi= ght > help persuade vendors that are not your employer to implement stuff like = this > :-) > =20 >> Now let's think of updating the various caches while roaming: >=20 > How much more do you think this sort of thing will help, assuming we do t= he > "100% feasible using the existing protocol" stuff above? >=20 >> NB: the above does not take care of the "defending the host's address >> on behalf of the sleeping node" problem. >=20 > An NS is 72 bytes, and if we do multicast snooping, then a sleeping node = is > only ever going to be woken up if a node with the same last 3 address byt= es > shows up. That should be extremely rare. >=20 > Cheers, > Lorenzo > -------------------------------------------------------------------- > 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 -------------------------------------------------------------------- --B_3472277807_552699 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Hi Tim,

For the ZigBee networks, we had to extend mDNS (a now expired draft c= alled Extended mDNS) since with a ROLL RPL mesh, each hop is defined as a li= nk (so there was no way to use ff02::fb and reach all devices in a single RO= LL RPL instance, or an attached subnet of Wi-Fi/HomePlug/etc. devices in a s= ingle residence).

I hope dnssd takes up this topic = and come up with a more complete standard that covers multi-hop subnets.

Don



=
From: Tim Chown <tjc@ecs.soton.ac.uk>
Date: Saturday, January 11, 2014 9:21 AM
To: Lorenzo Colitti <lorenzo@google.com>
Cc: 6= man Chairs <6man-chairs@tools= .ietf.org>, 6man WG <ipv6@ietf.org<= /a>>, Andrew =F0=9F=91=BD Yourtchenko <ayo= urtch@gmail.com>
Subject: R= e: Reducing the battery impact of ND

Hi,

On 11 Jan 2014, at 04:25, Lorenzo Colitti <lorenzo@google.com> wrote:

Andrew,

thank you for bringing solid dat= a and analysis to the equation. That is always appreciated.

On Sat, Jan 11, 2014 at 8:5= 7 AM, Andrew =F0=9F=91=BD Yourtchenko <ayourtch@gmail.com> wrote:
2) The bigger problem - the battery life:

This can be a real problem, yes. But as you say, I think we can miti= gate it well without changing ND at all.
 
WiFi is a pretty expensive thing to do, power-wise. To help extend the
battery, the mobile devices try very hard to shut off the radio
whenever they can. The wireless station would go to sleep, and inform
the AP about this fact - so the AP can buffer the frames for it [1].
Further optimizations in this area were introduced by 802.11e (WMM-PS)
[2], where the frames destined to workstation could be transmitted
more efficiently and radio duty cycle is reduced.

Spontaneous all-hosts multicasts interfere with these mechanisms, thus
the battery drain on the devices is much higher

=
One thing that I think we haven't discussed here is that in principle, = there are *very few* all-hosts multicasts - basically, only RA. Even RS is a= ll-routers multicast, not all hosts. So really the only thing we're talking = about is solicited-node multicasts for NS (and occasional unsolicited NAs, w= hich should only really happen when nodes change their MAC addresses. Note t= hat I'm not talking about malicious nodes here because any malicious node ca= n decide to spam the link with multicast messages regardless of what the ND = protocol looks like.

This is a useful reminder to consider the use/impact of multicast in the dn= ssd work, given one of the scenarios is Zigbee networks. mDNS uses ff02::fb = iirc.

Tim

I think that u= sing multicast instead of broadcast and defining solicited-node multicast ad= dresses based on the IID, were very wise choices. This is because there are = so many different groups (2^24), that even in very large networks, each soli= cited-node multicast group will likely only have one member. So - at least i= n principle - there are two layers at which the battery impact of NS packets= can be reduced to zero or close to zero:
  1. If the AP keeps = state of what MAC addresses have joined which multicast groups, it can selec= tively turn multicast NS into a set of unicast NS (L2 unicast; not L3 unicas= t). This will be a pretty significant bandwidth optimization both because a)= as you say, unicast is faster than multicast, and b) because one multicast = NS will almost certainly turn into only one unicast NS. Win/win.
    2. Even if the AP does not do #1, if the wifi chipset in the device keeps stat= e of what multicast groups the device has joined, then the wifi chipset can = simply drop packets that aren't interesting to the device's main CPU. From e= xperience we know that this can also lead to massive battery savings - the w= ifi chipset is basically on a lot of the time anyway, because it has to list= en for beacons and incoming packets, and this sort of filtering can be prett= y efficient.
That leaves RAs. Multicast RAs are a ba= ne for battery life, because every time a device joins the network, it sends= an RS. If the router responds with a multicast RA, then all devices on the = link get a packet which they didn't need. On large wifi networks, I've seen = this cause RAs once every 3-4 seconds, which is really painful in terms of b= attery life. Fortunately, there's an easy solution here: respond to router s= olicitations with unicast RAs sent to the sender. This is pretty trivial, an= d it doesn't require any state anywhere. There is a corner case where, if 10= 000 devices come online at the same time because the AP just booted up, you = can get a thundering herd problem and have to send 10000 unicast packets, bu= t this is can be optimized too: if the router sees that it's sending more th= an 100 solicited unicast RAs per second, it can simply send a multicast RA i= nstead.
 
- especially in a typical net= work where the mobile devices move, and might trigger an RS/RA on each = L2 roam between BSSIDs.

The client devic= es I'm familiar with don't send RSes when L2 roaming between BSSIDs on the s= ame SSID. Is this a bug? Should they?

I hear someone saying: "Yes, but this is all about wireless, DC is all
different story - it's all switches, they don't hold the state!" - yes
and no.

I'd argue that it's not "yes and no= ", it's just "no". The state required by the approaches I suggest above is t= he same amount of state as multicast snooping, and it's pretty much the same= amount of state required by the efficient ND approach - but it doesn't requ= ire complicating the ND protocol
 
Maybe wort= h to split the problem area into smaller subsets and see
whether a "cheaper" solutions are possible. Let's first take the
"multicast RAs" problem, and assume we do the below steps:

a) Allow the environments that wish to do so, to send solicited RAs
unicast. (standard already permits to do so).

Yes please!
 
b) Have the hosts restart the  Resilient RS [5] process at 1/2 or so of router lifetime expiry: the router now can have the heuristic to
know which hosts are supporting the "unicast RA update" mechanism
*and* did not receive the periodic RA which would have been sent
usually at 1/3 the lifetime expiry (three RAs per lifetime rule of
thumb).

Yes please!
 
c) bump up the allowable MaxRtrAdvInterval and AdvDefaultLifetime to
their maximum theoretically possible values (spec says the hosts
should already be able to handle those, I did not test though) - this
would allow to further reduce the periodic RA frequency, from 2.5
hours today to ~18.2 hours, or, if we feel adventurous, put all-ones
to be a "solicited-only RAs by default" - thus, unless another router
sends an RA with different lifetime, refreshing the router info
becomes host-driven, with an option for a router to override at any
time.

This sort of depends what device = you have. For example - on a mobile phone, receiving one packet every 2.5 ho= urs is *so far down* in the noise that it just doesn't matter. Your phone is= doing a massive amount of stuff already - it's syncing your email, receivin= g wifi beacons, checking calendar alarms, etc. etc. All of that uses way mor= e CPU than receiving one multicast RA.

There may be= other devices that have lower power requirements, though I'm not sure - per= haps these devices simply can't use 802.11-style wifi because it's too expen= sive, and so already have to use something like 6LowPAN. I don't know if the= re's a use case here.
 
These steps take care= of the "multicast RA" problem. But again, also,
each of them by itself brings incremental usefulness, and is doable on
a single device =3D> no "chicken and egg", they gradually shrink the
issue - and are compatible with the existing tweaks that solve the
same problem (in a more layer-violating way).

Care to work together on a document that provides operational guidanc= e to optimize battery impact of ND on wifi networks? Since they involve zero= protocol changes, v6ops would be a good candidate group for it. And it migh= t help persuade vendors that are not your employer to implement stuff like t= his :-)
 
Now let's think of updating the var= ious caches while roaming:

How much more= do you think this sort of thing will help, assuming we do the "100% feasibl= e using the existing protocol" stuff above?

NB: the above does not take care of the "defending the host's address
on behalf of the sleeping node" problem.

An NS is 72 bytes, and if we do multicast snooping, then a sleeping node i= s only ever going to be woken up if a node with the same last 3 address byte= s shows up. That should be extremely rare.

Cheers,<= /div>
Lorenzo
--------------------------------------------------------------------
IET= F IPv6 working group mailing list
ipv6@iet= f.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 -------------------------------------------------------------------- --B_3472277807_552699-- From cb.list6@gmail.com Sat Jan 11 09:47: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 C9FF81AE097 for ; Sat, 11 Jan 2014 09:47:28 -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 s0-KFS0n-5zF for ; Sat, 11 Jan 2014 09:47:27 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 279DA1AE070 for ; Sat, 11 Jan 2014 09:47:26 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id m15so2241780wgh.26 for ; Sat, 11 Jan 2014 09:47:16 -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=R7mN1zCUhYsfuT891lEBwF/FOnJGjORwdlqjU5EXDtQ=; b=iXpCjbKl2DOUKGr7qQtYDVFsIdLL/gOOusARamFV+ZkBekXMiofpok2DFlse5s7ED1 oUX3+9cJYE2Jtr0261LJUazpTP9jmA9LaXMmYtPag+pAzWiPZiQb3JbtvlVlYzw2Ekod WNNlQn2odFaozpE2Vo/mW6SngqBCDK7s+PY0GJXKYSBUp7dBlla7jc4ezh/7gvCTopKq 7dwntI3FZ3C/63jgV62K1dGL77QfUQuIknbzE7bTASClnKjSTCbtpitHYtrIU7tb/4qB VdQMNY0QH44QHe9pahCO3WK2Ji2ypbj3cCGFgedalkYPeEuJ1v4ur6IyEwuqLYBwHX1W KnsA== MIME-Version: 1.0 X-Received: by 10.194.60.103 with SMTP id g7mr14187916wjr.37.1389462436444; Sat, 11 Jan 2014 09:47:16 -0800 (PST) Received: by 10.216.221.195 with HTTP; Sat, 11 Jan 2014 09:47:16 -0800 (PST) Received: by 10.216.221.195 with HTTP; Sat, 11 Jan 2014 09:47:16 -0800 (PST) In-Reply-To: References: Date: Sat, 11 Jan 2014 09:47:16 -0800 Message-ID: Subject: Re: Reducing the battery impact of ND From: "cb.list6" To: Tim Chown Content-Type: multipart/alternative; boundary=047d7b86cfbcf401c804efb56e9c Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG , =?UTF-8?Q?Andrew_=F0=9F=91=BD_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: Sat, 11 Jan 2014 17:47:29 -0000 --047d7b86cfbcf401c804efb56e9c Content-Type: text/plain; charset=ISO-8859-1 I don't have much to offer this thread yet from a technical solution perspective, but i can share that Samsung and others deactivate ipv6 when the smartphone screen is off due to battery issues with ipv6 and wifi. This is not for anyone to judge, this is a problem statement and the current solution deployed on 10s (100s) of millions of hosts that go from dual-stack to single stack when the screen is off. We do do quantitative battery drain studies, and the ipv6-off configuration is meaningful better. These phones do a fair amount of background traffic to major ipv6 enabled clouds (google , facebook, yahoo ...) when the screen is of, so that is an ipv6 opportunity missed ... we need a better solution to take to the smartphone oems so they can keep ipv6 on and still meet the battery drain targets. We already know home routers dont get upgraded ever, so a client based solution would be nice. Said another way, i can help drive deployment of a client based solution. CB --047d7b86cfbcf401c804efb56e9c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I don't have much to offer this thread yet from a techni= cal solution perspective, but i can share that Samsung and others deactivat= e ipv6 when the smartphone screen is off due to battery issues with ipv6 an= d wifi.

This is not for anyone to judge, this is a problem statement= and the current solution deployed on 10s (100s) of millions of hosts that = go from dual-stack to single stack when the screen is off. We do do quantit= ative battery drain studies, and the ipv6-off configuration is meaningful b= etter.

These phones do a fair amount of background traffic to major= ipv6 enabled clouds (google , facebook, yahoo ...) when the screen is of, = so that is an ipv6 opportunity missed ... we need a better solution to take= to the smartphone oems so they can keep ipv6 on and still meet the battery= drain targets.

We already know home routers dont get upgraded ever, so a cl= ient based solution would be nice.=A0 Said another way, i can help drive de= ployment of a client based solution.

CB

--047d7b86cfbcf401c804efb56e9c-- From rajiva@cisco.com Sat Jan 11 12:20: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 436B81AE132 for ; Sat, 11 Jan 2014 12:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.638 X-Spam-Level: X-Spam-Status: No, score=-8.638 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, 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 YDDuPf5tB9HX for ; Sat, 11 Jan 2014 12:20:45 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCA81AE11F for ; Sat, 11 Jan 2014 12:20:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6293; q=dns/txt; s=iport; t=1389471634; x=1390681234; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9nPoMhsClzIS4HMzwaAK6d0dmLbk8OGOxiiV5Z6J4lc=; b=XKjpzd7IXeMEH9cIpm0HbjMSMwuKkGgi5SPBTuql14A3hk0xvDTO+Fy9 q78Kgjdb5WA5T89lV18fMzwzQ+Xrpde+1/rWXG/pizzSbLAvObUpb4RUq DYNe4/aGjfo+xFyFxLA/bqjJWpFkTalQ+caj/DHVwp4boC6MgICqWVR0W s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAGun0VKtJXG+/2dsb2JhbABagws4g1S2aBhvFnSCJgEBBAEBASBLCxACAQgEOwMCAgIfBgsUEQIEDgUbh1UDEQ2pEZUbDYUqEwSMdIErJj4EB4JvNYETBJFmhEWBbIxahTuDLYFq X-IronPort-AV: E=Sophos;i="4.95,644,1384300800"; d="scan'208,217";a="12182736" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-5.cisco.com with ESMTP; 11 Jan 2014 20:20:23 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0BKKNiB027853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 11 Jan 2014 20:20:23 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.165]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Sat, 11 Jan 2014 14:20:23 -0600 From: "Rajiv Asati (rajiva)" To: "cb.list6" Subject: Re: Reducing the battery impact of ND Thread-Topic: Reducing the battery impact of ND Thread-Index: AQHPDoVXlkEEUyIkD0G+tLCbRz+K7JqAKsYAgAAHGQD//8Yyfw== Date: Sat, 11 Jan 2014 20:20:22 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_FCF2A441E5CD41B98FFCC4B2F2C62541ciscocom_" MIME-Version: 1.0 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, =?utf-8?B?QW5kcmV3IPCfkb0gWW91cnRjaGVua28=?= , Tim Chown , 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, 11 Jan 2014 20:20:47 -0000 --_000_FCF2A441E5CD41B98FFCC4B2F2C62541ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2FtZXJvbiwNCg0KVGhhbmtzIGZvciBzaGFyaW5nIHRoaXMgdXNlZnVsIGluZm8uDQoNCg0K ZnJvbSBkdWFsLXN0YWNrIHRvIHNpbmdsZSBzdGFjayB3aGVuIHRoZSBzY3JlZW4gaXMgb2ZmLiBX ZSBkbyBkbyBxdWFudGl0YXRpdmUgYmF0dGVyeSBkcmFpbiBzdHVkaWVzLCBhbmQgdGhlIGlwdjYt b2ZmIGNvbmZpZ3VyYXRpb24gaXMgbWVhbmluZ2Z1bCBiZXR0ZXIuDQoNCkkgd291bGQgc3VzcGVj dCBpcHY0LW9mZiBjb25maWd1cmF0aW9uIHdvdWxkIGhhdmUgY29tcGFyYWJsZSByZXN1bHQuIElv VywgaXQgaXMgdGhlIHNpbmdsZS1zdGFjayB0aGF0IGRyYWlucyBsZXNzIGJhdHRlcnkgdGhhbiB0 aGF0IG9mIGR1YWwtc3RhY2suIE5vdGhpbmcgc3BlY2lmaWMgdG8gdjYsIG9uZSB3b3VsZCBob3Bl Lg0KDQpDaGVlcnMsDQpSYWppdg0KDQpPbiBKYW4gMTEsIDIwMTQsIGF0IDEyOjQ4IFBNLCAiY2Iu bGlzdDYiIDxjYi5saXN0NkBnbWFpbC5jb208bWFpbHRvOmNiLmxpc3Q2QGdtYWlsLmNvbT4+IHdy b3RlOg0KDQoNCkkgZG9uJ3QgaGF2ZSBtdWNoIHRvIG9mZmVyIHRoaXMgdGhyZWFkIHlldCBmcm9t IGEgdGVjaG5pY2FsIHNvbHV0aW9uIHBlcnNwZWN0aXZlLCBidXQgaSBjYW4gc2hhcmUgdGhhdCBT YW1zdW5nIGFuZCBvdGhlcnMgZGVhY3RpdmF0ZSBpcHY2IHdoZW4gdGhlIHNtYXJ0cGhvbmUgc2Ny ZWVuIGlzIG9mZiBkdWUgdG8gYmF0dGVyeSBpc3N1ZXMgd2l0aCBpcHY2IGFuZCB3aWZpLg0KDQpU aGlzIGlzIG5vdCBmb3IgYW55b25lIHRvIGp1ZGdlLCB0aGlzIGlzIGEgcHJvYmxlbSBzdGF0ZW1l bnQgYW5kIHRoZSBjdXJyZW50IHNvbHV0aW9uIGRlcGxveWVkIG9uIDEwcyAoMTAwcykgb2YgbWls bGlvbnMgb2YgaG9zdHMgdGhhdCBnbyBmcm9tIGR1YWwtc3RhY2sgdG8gc2luZ2xlIHN0YWNrIHdo ZW4gdGhlIHNjcmVlbiBpcyBvZmYuIFdlIGRvIGRvIHF1YW50aXRhdGl2ZSBiYXR0ZXJ5IGRyYWlu IHN0dWRpZXMsIGFuZCB0aGUgaXB2Ni1vZmYgY29uZmlndXJhdGlvbiBpcyBtZWFuaW5nZnVsIGJl dHRlci4NCg0KVGhlc2UgcGhvbmVzIGRvIGEgZmFpciBhbW91bnQgb2YgYmFja2dyb3VuZCB0cmFm ZmljIHRvIG1ham9yIGlwdjYgZW5hYmxlZCBjbG91ZHMgKGdvb2dsZSAsIGZhY2Vib29rLCB5YWhv byAuLi4pIHdoZW4gdGhlIHNjcmVlbiBpcyBvZiwgc28gdGhhdCBpcyBhbiBpcHY2IG9wcG9ydHVu aXR5IG1pc3NlZCAuLi4gd2UgbmVlZCBhIGJldHRlciBzb2x1dGlvbiB0byB0YWtlIHRvIHRoZSBz bWFydHBob25lIG9lbXMgc28gdGhleSBjYW4ga2VlcCBpcHY2IG9uIGFuZCBzdGlsbCBtZWV0IHRo ZSBiYXR0ZXJ5IGRyYWluIHRhcmdldHMuDQoNCldlIGFscmVhZHkga25vdyBob21lIHJvdXRlcnMg ZG9udCBnZXQgdXBncmFkZWQgZXZlciwgc28gYSBjbGllbnQgYmFzZWQgc29sdXRpb24gd291bGQg YmUgbmljZS4gIFNhaWQgYW5vdGhlciB3YXksIGkgY2FuIGhlbHAgZHJpdmUgZGVwbG95bWVudCBv ZiBhIGNsaWVudCBiYXNlZCBzb2x1dGlvbi4NCg0KQ0INCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCklFVEYgSVB2 NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KaXB2NkBpZXRmLm9yZzxtYWlsdG86aXB2NkBp ZXRmLm9yZz4NCkFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2lwdjYNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo= --_000_FCF2A441E5CD41B98FFCC4B2F2C62541ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PkhpIENhbWVyb24sPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MgZm9y IHNoYXJpbmcgdGhpcyB1c2VmdWwgaW5mby4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8cCBkaXI9Imx0ciI+ZnJvbSBkdWFs LXN0YWNrIHRvIHNpbmdsZSBzdGFjayB3aGVuIHRoZSBzY3JlZW4gaXMgb2ZmLiBXZSBkbyBkbyBx dWFudGl0YXRpdmUgYmF0dGVyeSBkcmFpbiBzdHVkaWVzLCBhbmQgdGhlIGlwdjYtb2ZmIGNvbmZp Z3VyYXRpb24gaXMgbWVhbmluZ2Z1bCBiZXR0ZXIuPC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgZGlyPSJsdHIiPkkgd291bGQgc3VzcGVjdCBpcHY0LW9mZiBjb25maWd1cmF0 aW9uIHdvdWxkIGhhdmUgY29tcGFyYWJsZSByZXN1bHQuIElvVywgaXQgaXMgdGhlIHNpbmdsZS1z dGFjayB0aGF0IGRyYWlucyBsZXNzIGJhdHRlcnkgdGhhbiB0aGF0IG9mIGR1YWwtc3RhY2suIE5v dGhpbmcgc3BlY2lmaWMgdG8gdjYsIG9uZSB3b3VsZCBob3BlLiZuYnNwOzwvcD4NCjwvZGl2Pg0K PGRpdj48YnI+DQpDaGVlcnMsDQo8ZGl2PlJhaml2PC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0K T24gSmFuIDExLCAyMDE0LCBhdCAxMjo0OCBQTSwgJnF1b3Q7Y2IubGlzdDYmcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpjYi5saXN0NkBnbWFpbC5jb20iPmNiLmxpc3Q2QGdtYWlsLmNvbTwvYT4m Z3Q7IHdyb3RlOjxicj4NCjxicj4NCjwvZGl2Pg0KPGRpdj48c3Bhbj48L3NwYW4+PC9kaXY+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+DQo8cCBkaXI9Imx0ciI+SSBkb24ndCBoYXZl IG11Y2ggdG8gb2ZmZXIgdGhpcyB0aHJlYWQgeWV0IGZyb20gYSB0ZWNobmljYWwgc29sdXRpb24g cGVyc3BlY3RpdmUsIGJ1dCBpIGNhbiBzaGFyZSB0aGF0IFNhbXN1bmcgYW5kIG90aGVycyBkZWFj dGl2YXRlIGlwdjYgd2hlbiB0aGUgc21hcnRwaG9uZSBzY3JlZW4gaXMgb2ZmIGR1ZSB0byBiYXR0 ZXJ5IGlzc3VlcyB3aXRoIGlwdjYgYW5kIHdpZmkuPC9wPg0KPHAgZGlyPSJsdHIiPlRoaXMgaXMg bm90IGZvciBhbnlvbmUgdG8ganVkZ2UsIHRoaXMgaXMgYSBwcm9ibGVtIHN0YXRlbWVudCBhbmQg dGhlIGN1cnJlbnQgc29sdXRpb24gZGVwbG95ZWQgb24gMTBzICgxMDBzKSBvZiBtaWxsaW9ucyBv ZiBob3N0cyB0aGF0IGdvIGZyb20gZHVhbC1zdGFjayB0byBzaW5nbGUgc3RhY2sgd2hlbiB0aGUg c2NyZWVuIGlzIG9mZi4gV2UgZG8gZG8gcXVhbnRpdGF0aXZlIGJhdHRlcnkgZHJhaW4gc3R1ZGll cywgYW5kIHRoZQ0KIGlwdjYtb2ZmIGNvbmZpZ3VyYXRpb24gaXMgbWVhbmluZ2Z1bCBiZXR0ZXIu IDwvcD4NCjxwIGRpcj0ibHRyIj5UaGVzZSBwaG9uZXMgZG8gYSBmYWlyIGFtb3VudCBvZiBiYWNr Z3JvdW5kIHRyYWZmaWMgdG8gbWFqb3IgaXB2NiBlbmFibGVkIGNsb3VkcyAoZ29vZ2xlICwgZmFj ZWJvb2ssIHlhaG9vIC4uLikgd2hlbiB0aGUgc2NyZWVuIGlzIG9mLCBzbyB0aGF0IGlzIGFuIGlw djYgb3Bwb3J0dW5pdHkgbWlzc2VkIC4uLiB3ZSBuZWVkIGEgYmV0dGVyIHNvbHV0aW9uIHRvIHRh a2UgdG8gdGhlIHNtYXJ0cGhvbmUgb2VtcyBzbyB0aGV5IGNhbg0KIGtlZXAgaXB2NiBvbiBhbmQg c3RpbGwgbWVldCB0aGUgYmF0dGVyeSBkcmFpbiB0YXJnZXRzLiA8L3A+DQo8cCBkaXI9Imx0ciI+ V2UgYWxyZWFkeSBrbm93IGhvbWUgcm91dGVycyBkb250IGdldCB1cGdyYWRlZCBldmVyLCBzbyBh IGNsaWVudCBiYXNlZCBzb2x1dGlvbiB3b3VsZCBiZSBuaWNlLiZuYnNwOyBTYWlkIGFub3RoZXIg d2F5LCBpIGNhbiBoZWxwIGRyaXZlIGRlcGxveW1lbnQgb2YgYSBjbGllbnQgYmFzZWQgc29sdXRp b24uDQo8L3A+DQo8cCBkaXI9Imx0ciI+Q0I8L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj48c3Bhbj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvc3Bhbj48YnI+ DQo8c3Bhbj5JRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0K PHNwYW4+PGEgaHJlZj0ibWFpbHRvOmlwdjZAaWV0Zi5vcmciPmlwdjZAaWV0Zi5vcmc8L2E+PC9z cGFuPjxicj4NCjxzcGFuPkFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiA8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYiPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pcHY2PC9hPjwvc3Bhbj48YnI+DQo8c3Bhbj4tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTwvc3Bhbj48YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_FCF2A441E5CD41B98FFCC4B2F2C62541ciscocom_-- From ayourtch@gmail.com Sat Jan 11 11: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 3BD451AE06E for ; Sat, 11 Jan 2014 11:58:58 -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 elkumBw2fwyP for ; Sat, 11 Jan 2014 11:58:56 -0800 (PST) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3911AE06D for ; Sat, 11 Jan 2014 11:58:56 -0800 (PST) Received: by mail-qa0-f41.google.com with SMTP id w8so99790qac.0 for ; Sat, 11 Jan 2014 11:58:45 -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:content-transfer-encoding; bh=ZCoe3BYSWp46viXU1eCl2H/6pa3rKhiaXBqLVTJWzl8=; b=F+chCALlwVtBmzCE1JdNyR9X2sp1uV3EbEIWpyJ3hJivlQcCDmZi7ICTCReOA/nqJr 9tQS/Z8EHSq2LxhAz5ieYJpZDMqQYVjahdjtTySsLTGZ5P/sHS8tXV0d/oo771VsGxOb Udbw5wLFdP5sTb7RB0Xx3jnO2ao27ULp/Q0moTZ4mdfBsOmR4X+JG1At1IW0/nlDlFaw h9RUlrLGD1bqQvV/XixKoMJkHCr0XeeThg6ZhbeLwP0EkN4lDNL1N0F2X9TDZnPRqKNS VMsTb4aZGxXRgn55aG9n10ECfIKrR5oBxj6hvffSY4aZ0qYeIlwam/6R+7Xf9qyjRC7n J52Q== MIME-Version: 1.0 X-Received: by 10.49.52.102 with SMTP id s6mr22254841qeo.60.1389470325874; Sat, 11 Jan 2014 11:58:45 -0800 (PST) Received: by 10.96.133.39 with HTTP; Sat, 11 Jan 2014 11:58:45 -0800 (PST) In-Reply-To: References: Date: Sat, 11 Jan 2014 19:58:45 +0000 Message-ID: Subject: Re: Reducing the battery impact of ND From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: Lorenzo Colitti Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 11 Jan 2014 15:17:39 -0800 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 11 Jan 2014 19:58:58 -0000 Lorenzo, On 1/11/14, Lorenzo Colitti wrote: > On Sat, Jan 11, 2014 at 8:57 AM, Andrew =F0=9F=91=BD Yourtchenko > wrote: > >> 2) The bigger problem - the battery life: >> > > This can be a real problem, yes. But as you say, I think we can mitigate = it > well without changing ND at all. > assuming some cooperation between L2 and L3, yes :-) >> Spontaneous all-hosts multicasts interfere with these mechanisms, thus >> the battery drain on the devices is much higher > > > One thing that I think we haven't discussed here is that in principle, > there are *very few* all-hosts multicasts - basically, only RA. Even RS i= s Thanks to Tim for mentioning dns-sd. It is another big offender. Funnily enough, both RAs and DNS-SD are primarily acting up in the larger-scale multi-AP environments, due to roaming: according to my experiments, at least an iPhone roaming from an AP to AP acts as if it has reattached to another link (and for good reason - there can be plenty of setups where this is the only robust behavior). In the home WLAN, the impact of the problem is quite less. Still not zero, but less - I am enjoying not having to maintain the DNS for the gadgets at home and just run mDNS on all of them - and the battery life is okay-ish. > all-routers multicast, not all hosts. So really the only thing we're > talking about is solicited-node multicasts for NS (and occasional > unsolicited NAs, which should only really happen when nodes change their > MAC addresses. Note that I'm not talking about malicious nodes here becau= se > any malicious node can decide to spam the link with multicast messages > regardless of what the ND protocol looks like. > While a node can jam the airtime with sending the packets, all packets first have to travel to the AP, which then retransmits them to all clients. So, in the environments where you can not trust the wireless clients, you can still keep the handle on the clients (with the L2 tweaks again, of course). > I think that using multicast instead of broadcast and defining > solicited-node multicast addresses based on the IID, were very wise > choices. This is because there are so many different groups (2^24), that > even in very large networks, each solicited-node multicast group will > likely only have one member. This is indeed quite an elegant approach. But, the funny part - an intermediate L2.5 can track who has which address based on DAD/traffic, or multicast group membership, or, both. Realistically you have to do both, and this is how the IPv4 already has the similarly (and maybe more) efficient implementation of ARP for WiFi, for those implementations that care to optimize that stuff. Nonetheless, the 2^24 groups do allow additional flexibility. > So - at least in principle - there are two > layers at which the battery impact of NS packets can be reduced to zero o= r > close to zero: > > 1. If the AP keeps state of what MAC addresses have joined which > multicast groups, it can selectively turn multicast NS into a set of > unicast NS (L2 unicast; not L3 unicast). This will be a pretty > significant > bandwidth optimization both because a) as you say, unicast is faster > than > multicast, and b) because one multicast NS will almost certainly turn > into > only one unicast NS. Win/win. Yes. MLD snooping++. > 2. Even if the AP does not do #1, if the wifi chipset in the device > keeps state of what multicast groups the device has joined, then the > wifi > chipset can simply drop packets that aren't interesting to the device'= s > main CPU. From experience we know that this can also lead to massive > battery savings - the wifi chipset is basically on a lot of the time > anyway, because it has to listen for beacons and incoming packets, and > this > sort of filtering can be pretty efficient. > Do you have a pointer to read up more on these results ? AFAIK, the "radio is always on" is not always true, because: 1) each WiFi packet has a field ("duration/id") which determines how long the sending station will take for the transmission, so the radio can be in a tiny "nap" mode for this period (since it *knows* the carrier is busy anyway). 2) a node going to sleep can indicate so to an AP, and can sleep until an AP notices incoming frame to be sent onto the air, buffers it, and sends a beacon an indication that there is traffic for this station. Till then the radio can stay in a relatively low power mode. (I'd need to refresh what happens for the multicast packets in this case). Once the radio sees that it has pending packets, it wases up and sends the poll packet to the AP, which then resends the buffered packets to the station, which are then acked by the station.. This "pending traffic" stuff is a bitmap - so I'd imagine not a whole lot of processing is possible besides that. so, in my understanding, lone packets are bad, whatever they are. > That leaves RAs. Multicast RAs are a bane for battery life, because every > time a device joins the network, it sends an RS. If the router responds > with a multicast RA, then all devices on the link get a packet which they > didn't need. On large wifi networks, I've seen this cause RAs once every > 3-4 seconds, which is really painful in terms of battery life. Fortunatel= y, > there's an easy solution here: respond to router solicitations with unica= st > RAs sent to the sender. This is pretty trivial, and it doesn't require an= y > state anywhere. There is a corner case where, if 10000 devices come onlin= e > at the same time because the AP just booted up, you can get a thundering > herd problem and have to send 10000 unicast packets, but this is can be > optimized too: if the router sees that it's sending more than 100 solicit= ed > unicast RAs per second, it can simply send a multicast RA instead. One AP can get up to 2007 clients, so it will be a multitude of APs that will have to boot up and come online. Each client, before it comes to sending the RS, has to exchange at least 4 packets with the AP (authentication request/response, association request/response). This of course has to happen over the air - which will naturally rate-limit the process. In short: you *really* don't want APs with 10000 connected clients to lose them all at once - with or without IPv6 :-) - so for realistic scenarios, unicast solicited RAs might work fine. (I don't have the practical experience of rebooting a 10000-node network in such a situation, can't tell where the bottleneck is going to be :-) > > >> - especially in a typical network where the mobile devices move, and >> might >> trigger an RS/RA on each L2 roam between BSSIDs. >> > > The client devices I'm familiar with don't send RSes when L2 roaming > between BSSIDs on the same SSID. Is this a bug? Should they? Thinking more - I might be mixing the DNS-SD packets being sent. I tested in the office capturing the DNS-SD traffic (also all-hosts) while walking around. I do not remember if I captured the RA. I'll retest on monday. Intuitively, in the well-behaved enterprise environment we probably don't want to be gratuitous about multicast - the infra knows all well about the node. But I can easily see where a mobile device manufacturer, confronted with a multitude of weird 2-3 uncoordinated APs home WLAN setups, could be compelled to flash the packets "just to be sure". > > I hear someone saying: "Yes, but this is all about wireless, DC is all >> different story - it's all switches, they don't hold the state!" - yes >> and no. > > > I'd argue that it's not "yes and no", it's just "no". The state required = by > the approaches I suggest above is the same amount of state as multicast > snooping, and it's pretty much the same amount of state required by the > efficient ND approach - but it doesn't require complicating the ND protoc= ol Lots of enterprises have to migrate VMs around the place - which, in the absence of any hooks, for the host looks like it magically wakes up in a completely different place in the network, and for the network looks like the host has disappeared in one place and reappeared in the other. And presumably there is a L2-like link between these two places, with X layers of CAM tables, at the same time some parts of this stuff run atop the overlays across the L3 network. All this time, you want to ensure that this MAC address that reappeared, is a legitimate MAC address, and not someone spoofing your server. Also, on the WiFi the roaming decisions are host-driven and undoable (of the reauthentication to the new AP fails, the host can stay at the old AP), in the VM migration case they are external to the host and host has no control over them. So, it is not the same situation. > > >> Maybe worth to split the problem area into smaller subsets and see >> whether a "cheaper" solutions are possible. Let's first take the >> "multicast RAs" problem, and assume we do the below steps: >> >> a) Allow the environments that wish to do so, to send solicited RAs >> unicast. (standard already permits to do so). >> > > Yes please! > > >> b) Have the hosts restart the Resilient RS [5] process at 1/2 or so >> of router lifetime expiry: the router now can have the heuristic to >> know which hosts are supporting the "unicast RA update" mechanism >> *and* did not receive the periodic RA which would have been sent >> usually at 1/3 the lifetime expiry (three RAs per lifetime rule of >> thumb). >> > > Yes please! > > >> c) bump up the allowable MaxRtrAdvInterval and AdvDefaultLifetime to >> their maximum theoretically possible values (spec says the hosts >> should already be able to handle those, I did not test though) - this >> would allow to further reduce the periodic RA frequency, from 2.5 >> hours today to ~18.2 hours, or, if we feel adventurous, put all-ones >> to be a "solicited-only RAs by default" - thus, unless another router >> sends an RA with different lifetime, refreshing the router info >> becomes host-driven, with an option for a router to override at any >> time. >> > > This sort of depends what device you have. For example - on a mobile phon= e, > receiving one packet every 2.5 hours is *so far down* in the noise that i= t > just doesn't matter. Your phone is doing a massive amount of stuff alread= y > - it's syncing your email, receiving wifi beacons, checking calendar > alarms, etc. etc. All of that uses way more CPU than receiving one > multicast RA. > > There may be other devices that have lower power requirements, though I'm > not sure - perhaps these devices simply can't use 802.11-style wifi becau= se > it's too expensive, and so already have to use something like 6LowPAN. I > don't know if there's a use case here. if you go unicast-only-RA (the all-ones case), you can achieve all the benefits that you speficied power-savings wise, with zero changes to the pipes between the router and the hosts. Some networks may have control over the hosts, limited control over the routers, and less of control over the wifi inbetween. Also, for a major part of WiFi networks (university campus, enterprise, large-scale event, etc) 18 hours is "infinity" for practical purposes: a huge percentage of the clients will not be on the network for that long. This would provide a valuable pain relief mechanism in case there is some multicast-related issue which prevents the multicast RAs reaching the client. The other reason for this, besides the above, is that since the host is required to handle all the ranges of the lifetimes anyway, we might as well have the behavior 100% predictable and they do not blow up if someone decides to send such a packet. > > >> These steps take care of the "multicast RA" problem. But again, also, >> each of them by itself brings incremental usefulness, and is doable on >> a single device =3D> no "chicken and egg", they gradually shrink the >> issue - and are compatible with the existing tweaks that solve the >> same problem (in a more layer-violating way). >> > > Care to work together on a document that provides operational guidance to > optimize battery impact of ND on wifi networks? Since they involve zero > protocol changes, v6ops would be a good candidate group for it. And it > might help persuade vendors that are not your employer to implement stuff > like this :-) Definitely interested! Let's sync unicast. > > >> Now let's think of updating the various caches while roaming: >> > > How much more do you think this sort of thing will help, assuming we do t= he > "100% feasible using the existing protocol" stuff above? I don't know. Depends on how many L2 belts and suspenders we are aiming to make unnecessary. I suppose we could see how much remains after axing the issue with the existing protocol. > > NB: the above does not take care of the "defending the host's address >> on behalf of the sleeping node" problem. >> > > An NS is 72 bytes, and if we do multicast snooping, then a sleeping node = is > only ever going to be woken up if a node with the same last 3 address byt= es > shows up. That should be extremely rare. > As I wrote above, my understanding was by the time you are awake enough to poke into the MAC address, you are way too much awake already :-) But as I said I'd be interested to see more info to educate myself better on this ! --a From ayourtch@gmail.com Sat Jan 11 12:18: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 DEAAA1AE058 for ; Sat, 11 Jan 2014 12:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1 X-Spam-Level: * X-Spam-Status: No, score=1 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, 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 8dETKXm2KoQr for ; Sat, 11 Jan 2014 12:18:04 -0800 (PST) Received: from mail-qe0-x229.google.com (mail-qe0-x229.google.com [IPv6:2607:f8b0:400d:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id B11141AE020 for ; Sat, 11 Jan 2014 12:18:03 -0800 (PST) Received: by mail-qe0-f41.google.com with SMTP id gh4so5905622qeb.0 for ; Sat, 11 Jan 2014 12:17:53 -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=b5SddNod4cTPqW+b7ws7TyALgPiiu0EoXYnreSJvJOA=; b=eXFEEFBx/wMLPYLx3MIVrUGBnJrpPSPG4oagavhTwdRyfQMIvcgnGGbrt4VDij7tJe krZRZ6LTSWOVcWgk+M/u8GJPy4Bkjzjs5On7MWwSsDRjm1shKNtCmio6ffFbE2bBJJLs P3ILnjReYDunliIB9m2r5RPmWpu8AvHv+ze/PPrfC/bW0IM0WKeikUpKfL21K1YQPaJw pffnz28FUiRX9RqDjDXLjHsVBD+NiJPtXo0qDcUJ6CGj1OM16QZqs9c4rzCwY6vS0BbO IqDf6EQGR5NC7w1QZhXraLXh/NN5K1LG7TRkFLWvs150cyy0FIBh4uQNHPJMkwIfVmMW jeWQ== MIME-Version: 1.0 X-Received: by 10.229.97.134 with SMTP id l6mr21957493qcn.11.1389471473285; Sat, 11 Jan 2014 12:17:53 -0800 (PST) Received: by 10.96.133.39 with HTTP; Sat, 11 Jan 2014 12:17:53 -0800 (PST) In-Reply-To: References: Date: Sat, 11 Jan 2014 20:17:53 +0000 Message-ID: Subject: Re: Reducing the battery impact of ND From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: "cb.list6" Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Sat, 11 Jan 2014 15:17:40 -0800 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Tim Chown , 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, 11 Jan 2014 20:18:05 -0000 On 1/11/14, cb.list6 wrote: > I don't have much to offer this thread yet from a technical solution > perspective, but i can share that Samsung and others deactivate ipv6 when > the smartphone screen is off due to battery issues with ipv6 and wifi. > > This is not for anyone to judge, this is a problem statement and the > current solution deployed on 10s (100s) of millions of hosts that go from > dual-stack to single stack when the screen is off. We do do quantitative > battery drain studies, and the ipv6-off configuration is meaningful better. Is this with or without IPv6 configured (thus, RAs) on the home gateway ? I'm keeping my fingers crossed that this could be one of the cases where the WiFi chipset is IPv4-smart and IPv6-unsmart, therefore requiring the CPU for anything IPv6 related.. Did you have a chance to further narrow down the root cause of this ? --a From ayourtch@gmail.com Sat Jan 11 12: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 C33501ADF46 for ; Sat, 11 Jan 2014 12:44:32 -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 B73wRt73eLXs for ; Sat, 11 Jan 2014 12:44:30 -0800 (PST) Received: from mail-qe0-x232.google.com (mail-qe0-x232.google.com [IPv6:2607:f8b0:400d:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 146D81AC829 for ; Sat, 11 Jan 2014 12:44:29 -0800 (PST) Received: by mail-qe0-f50.google.com with SMTP id 1so5798731qec.37 for ; Sat, 11 Jan 2014 12:44:19 -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=UyF1YPsRYsMiqdGvMJFSG5jhU7A+Q+RzG73+G89Wbb0=; b=ta6f/lYj0XAUBk0IZzz8E0OB7171T0aTY1NODlxOKANqLrt/ydJuTYmigp13aF7DcI 080qwRs/dUgn9j47j7zTYRryfC2OeAEbDDbZcY9uZOxAK84gK9WFLIZDPACW79C6wVFh 0cSK53pPjvQO+kQujk6ZuclDNI57tJPu7klvdUKH4eEUE1w4ZfjfwzX3BNS246CMf0ce QKFktxQGAmO3uSOCxKfx6k/NG1J5/WrWnpquBMzFsFUc4ZKzxUOB2SBF9FSD4rgXyR57 scGqm7u5LXhq735OUo7nYXYb4hZcDnZDH+E6EUjxGXX74pmNrRKYwmDDqMGR+mr0L/rs tL9A== MIME-Version: 1.0 X-Received: by 10.49.53.100 with SMTP id a4mr22488268qep.44.1389473059578; Sat, 11 Jan 2014 12:44:19 -0800 (PST) Received: by 10.96.133.39 with HTTP; Sat, 11 Jan 2014 12:44:19 -0800 (PST) In-Reply-To: References: Date: Sat, 11 Jan 2014 20:44:19 +0000 Message-ID: Subject: Re: Reducing the battery impact of ND From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: Lorenzo Colitti Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Sat, 11 Jan 2014 15:17:40 -0800 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 11 Jan 2014 20:44:33 -0000 On 1/11/14, Lorenzo Colitti wrote: > An NS is 72 bytes, and if we do multicast snooping, then a sleeping node is > only ever going to be woken up if a node with the same last 3 address bytes > shows up. That should be extremely rare. Found this: http://cseweb.ucsd.edu/~snoeren/papers/slomo-nsdi13.pdf The exhibit of interest is table 1: if I interpret it correctly, merely receiving the frame is 30% more power consumption compared to idle. --a From Fred.L.Templin@boeing.com Mon Jan 13 13:21: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 48C621AE1C0; Mon, 13 Jan 2014 13:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 iFJE7RiJJtom; Mon, 13 Jan 2014 13:21:06 -0800 (PST) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 858111AE196; Mon, 13 Jan 2014 13:21:06 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s0DLKt0I019516; Mon, 13 Jan 2014 15:20:55 -0600 Received: from XCH-PHX-209.sw.nos.boeing.com (xch-phx-209.sw.nos.boeing.com [130.247.25.29]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s0DLKPrl018646 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 13 Jan 2014 15:20:48 -0600 Received: from XCH-BLV-308.nw.nos.boeing.com (2002:82f7:19dc::82f7:19dc) by XCH-PHX-209.sw.nos.boeing.com (2002:82f7:191d::82f7:191d) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jan 2014 13:20:35 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-BLV-308.nw.nos.boeing.com ([169.254.8.220]) with mapi id 14.03.0158.001; Mon, 13 Jan 2014 13:20:35 -0800 From: "Templin, Fred L" To: "v6ops@ietf.org" , "ipv6@ietf.org" Subject: FW: I-D Action: draft-templin-aerolink-02.txt Thread-Topic: I-D Action: draft-templin-aerolink-02.txt Thread-Index: AQHPEKQ4UlaOJp9uoECc6bip3DA7E5qDJ5yQ Date: Mon, 13 Jan 2014 21:20:34 +0000 Message-ID: <2134F8430051B64F815C691A62D98318198AFF@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.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, 13 Jan 2014 21:21:08 -0000 Hi, Here is an update to AERO that makes some significant changes based on recent list discussions. Most importantly, it deprecates the use of RS/RA on AERO links (now, only NS/NA and Redirect are used). This really is close to a finished product now. This is how IPv6 can be deployed in enterprise network without having to cause upheaval in day-to-day operations. Comments? Fred fred.l.templin@boeing.com -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Monday, January 13, 2014 1:13 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-templin-aerolink-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Transmission of IPv6 Packets over AERO Links Author : Fred L. Templin Filename : draft-templin-aerolink-02.txt Pages : 24 Date : 2014-01-13 Abstract: This document specifies the operation of IPv6 over tunnel virtual Non-Broadcast, Multiple Access (NBMA) links using Automatic Extended Route Optimization (AERO). Nodes attached to AERO links can exchange packets via trusted intermediate routers on the link that provide forwarding services to reach off-link destinations and/or redirection services to inform the node of an on-link neighbor that is closer to the final destination. Operation of the IPv6 Neighbor Discovery (ND) protocol over AERO links is based on an IPv6 link local address format known as the AERO address. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-aerolink/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-templin-aerolink-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-templin-aerolink-02 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. 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 ing-wher.chen@ericsson.com Mon Jan 13 14:36: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 EC2391AE1B7 for ; Mon, 13 Jan 2014 14:36:57 -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 I83OrvzdwMpX for ; Mon, 13 Jan 2014 14:36:56 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 017FC1ADFAE for ; Mon, 13 Jan 2014 14:36:55 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-4b-52d46a798967 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 45.DC.23183.97A64D25; Mon, 13 Jan 2014 23:36:41 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0347.000; Mon, 13 Jan 2014 17:36:43 -0500 From: Ing-Wher Chen To: "ipv6@ietf.org" Subject: FW: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt Thread-Topic: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt Thread-Index: AQHPDmY2hGYF66RRbk+N6Vv6p523J5qDMmww Date: Mon, 13 Jan 2014 22:36:43 +0000 Message-ID: References: <20140111004402.10451.90724.idtracker@ietfa.amsl.com> In-Reply-To: <20140111004402.10451.90724.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyuXRPuG5l1pUgg47jMhYvz75ncmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsYLF1kLdolVTF3+lr2B8YNoFyMnh4SAicSx5zdZIGwxiQv3 1rN1MXJxCAkcYZR4vHgaM4SznFFizqpmdpAqNgEDiQ0ftzCB2CICyhIzus+xgdjCApESb/fO YoSIR0mcXLaFFcI2kmhds5gZxGYRUJWYsnUx2DZeAW+J/l/LweqFBBwlnr/eCBTn4OAUcJJ4 +6saJMwIdND3U2vAVjELiEvcejKfCeJQAYkle84zQ9iiEi8f/2OFsJUlvs95BDaGWUBTYv0u fYhWRYkp3Q/ZIbYKSpyc+YRlAqPoLCRTZyF0zELSMQtJxwJGllWMHKXFqWW56UYGmxiBQX9M gk13B+Oel5aHGKU5WJTEeb+8dQ4SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwFjhHP6dM2T1 RlbWY8+kD16q39AtNS+nYNbzuTpyvLmflsdE73GbU7PotNni7ulhddfY4oLr1+pKX125VIZf L7yvO9D0z99lizjXqCSe3r/CLiDoBOszzrdJkj55x+ef7lbXSnF+P+vBQQ+ZjxsloiMusb/b li7PeuDtVJGa1fFpUV9X7ZLIOqLEUpyRaKjFXFScCAAaN+KoSAIAAA== 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, 13 Jan 2014 23:11:52 -0000 SGVsbG8sDQoNClRoZSBpbmZvcm1hdGlvbmFsIGRyYWZ0IGJlbG93IGRvY3VtZW50cyBFcmljc3Nv bidzIHNvbHV0aW9uLCBkZXBsb3llZCBzaW5jZSBlYXJseSAyMDEzLCByZWdhcmRpbmcgTWlrYWVs J3MgY29uY2VybiBpbiB0aGUgcmVjZW50IGRpc2N1c3Npb24gYWJvdXQgTkQgZGVuaWFsLW9mLXNl cnZpY2UgYXR0YWNrcy4gIFRoZSBkcmFmdCBhbHNvIGVsYWJvcmF0ZXMgb24gTG9yZW56bydzIHBv aW50IHJlZ2FyZGluZyBkaXNjb3ZlcmluZyBuZWlnaGJvcnMgYmFzZWQgb24gREFELU5TIHBhY2tl dHMuDQoNClRoYW5rcywNCkhlbGVuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmddIA0KU2VudDogRnJpZGF5LCBKYW51YXJ5IDEwLCAyMDE0IDQ6NDQgUE0NClRvOiBKb2VsIEhh bHBlcm47IEluZy1XaGVyIENoZW47IEpvZWwgSGFscGVybjsgSW5nLVdoZXIgQ2hlbg0KU3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYWxwZXJuLTZtYW4tbmQtcHJl LXJlc29sdmUtYWRkci0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaGFs cGVybi02bWFuLW5kLXByZS1yZXNvbHZlLWFkZHItMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IEkuIENoZW4gYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5 Lg0KDQpOYW1lOgkJZHJhZnQtaGFscGVybi02bWFuLW5kLXByZS1yZXNvbHZlLWFkZHINClJldmlz aW9uOgkwMA0KVGl0bGU6CQlUcmlnZ2VyaW5nIE5EIEFkZHJlc3MgUmVzb2x1dGlvbiBvbiBSZWNl aXZpbmcgREFELU5TDQpEb2N1bWVudCBkYXRlOgkyMDE0LTAxLTEwDQpHcm91cDoJCUluZGl2aWR1 YWwgU3VibWlzc2lvbg0KUGFnZXM6CQk3DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaGFscGVybi02bWFuLW5kLXByZS1yZXNvbHZlLWFk ZHItMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaGFscGVybi02bWFuLW5kLXByZS1yZXNvbHZlLWFkZHIvDQpIdG1saXplZDogICAg ICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFscGVybi02bWFuLW5kLXByZS1y ZXNvbHZlLWFkZHItMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZHJhZnQgcHJvcG9zZXMgYSBu ZXcgb3B0aW9uYWwgZXZlbnQgdG8gdHJpZ2dlciBhZGRyZXNzDQogICByZXNvbHV0aW9uIHVzaW5n IElQdjYgTmVpZ2hib3IgRGlzY292ZXJ5LiAgVGhpcyBoZWxwcyBvcHRpbWl6ZSByb3V0ZXINCiAg IHBlcmZvcm1hbmNlLCBhbmQgY2FuIGhlbHAgbWl0aWdhdGUgY2VydGFpbiBwb3RlbnRpYWwgTkQt cmVsYXRlZA0KICAgZGVuaWFsLW9mLXNlcnZpY2UgYXR0YWNrcy4gIFVwb24gcmVjZWl2aW5nIGEg REFELU5TIG1lc3NhZ2UsIHRoZQ0KICAgbmVpZ2hib3Igc29saWNpdGF0aW9uIG1lc3NhZ2UgdXNl ZCB0byBkZXRlY3QgZHVwbGljYXRlIGFkZHJlc3NlcywgaWYNCiAgIHRoZSB0YXJnZXQgYWRkcmVz cyBlbmNvZGVkIGluIHRoZSBEQUQtTlMgaXMgbm90IGEgZHVwbGljYXRlIGFkZHJlc3MsDQogICB0 aGUgcmVjZWl2aW5nIGRldmljZSByZXNwb25kcyBieSB0cmlnZ2VyaW5nIGFkZHJlc3MgcmVzb2x1 dGlvbiBmb3INCiAgIHRoZSB0YXJnZXQgYWRkcmVzcyBpbiB0aGUgREFELU5TLCBpbiBwcmVwYXJh dGlvbiBmb3IgZXhwZWN0YW50IGZ1dHVyZQ0KICAgY29tbXVuaWNhdGlvbiB3aXRoIHRoZSBzZW5k aW5nIGRldmljZS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1 Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From ing-wher.chen@ericsson.com Mon Jan 13 14:52: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 1FC8A1AE00A for ; Mon, 13 Jan 2014 14:52:54 -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 N_F7bUDmzWkD for ; Mon, 13 Jan 2014 14:52:52 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5469A1A1F1B for ; Mon, 13 Jan 2014 14:52:52 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-ba-52d46e3936ad Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 78.0C.04556.93E64D25; Mon, 13 Jan 2014 23:52:41 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0347.000; Mon, 13 Jan 2014 17:52:41 -0500 From: Ing-Wher Chen To: "ipv6@ietf.org" Subject: RE: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt Thread-Topic: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt Thread-Index: AQHPDmY2hGYF66RRbk+N6Vv6p523J5qDMmwwgAATMeA= Date: Mon, 13 Jan 2014 22:52:40 +0000 Message-ID: References: <20140111004402.10451.90724.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyuXSPt65l3pUgg/s3DC1enn3P5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJ3HbzIWdElVtH1czdTAuEWyi5GTQ0LAROLrj6eMELaYxIV7 69m6GLk4hASOMEq8e3KEHcJZziix+9FxZpAqNgEDiQ0ftzCB2CICyhIzus+xgdjCApESM9uu MkLEoyROLtvCCmFbSXyfuhYsziKgKtH2cR9YPa+At8S/LXPAZgoJOEnsOTqDBcRmBLri+6k1 YPOZBcQlbj2ZzwRxnYDEkj3nmSFsUYmXj/+xQtjKEt/nPALq5QCq15RYv0sfolVRYkr3Q3aI VYISJ2c+YZnAKDILydRZCB2zkHTMQtKxgJFlFSNHaXFqWW66keEmRmB4H5Ngc9zBuOCT5SFG aQ4WJXHeL2+dg4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwsi4vVkg4dC7D+8LphXr7jPfo OtRXhacYPt717JH+Va5/rimPDUomSCp0zbP6EbKaP7r/6RNePY0VQTrrrs16f3T+hcU/V12t ELVyzV3otWEdh5fOn4ccmbw7vuszi/w2twiXilz17lr570PSv71NT2rcZy02DG7b8qR3guWi 50bHn6XUfVUoUGIpzkg01GIuKk4EABh2QiM9AgAA 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, 13 Jan 2014 23:28:33 -0000 UGxlYXNlIG5vdGUgdGhhdCB3ZSdyZSBhY3RpdmVseSB3b3JraW5nIHdpdGggRXJpY3Nzb24ncyBs ZWdhbCBkZXBhcnRtZW50IG9uIGFuIElQUiBkaXNjbG9zdXJlIHJlZ2FyZGluZyB0aGUgZHJhZnQu DQoNClRoYW5rcywNCkhlbGVuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJ bmctV2hlciBDaGVuIA0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDEzLCAyMDE0IDI6MzcgUE0NClRv OiAnaXB2NkBpZXRmLm9yZycNClN1YmplY3Q6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWhhbHBlcm4tNm1hbi1uZC1wcmUtcmVzb2x2ZS1hZGRyLTAwLnR4dA0KDQpIZWxs bywNCg0KVGhlIGluZm9ybWF0aW9uYWwgZHJhZnQgYmVsb3cgZG9jdW1lbnRzIEVyaWNzc29uJ3Mg c29sdXRpb24sIGRlcGxveWVkIHNpbmNlIGVhcmx5IDIwMTMsIHJlZ2FyZGluZyBNaWthZWwncyBj b25jZXJuIGluIHRoZSByZWNlbnQgZGlzY3Vzc2lvbiBhYm91dCBORCBkZW5pYWwtb2Ytc2Vydmlj ZSBhdHRhY2tzLiAgVGhlIGRyYWZ0IGFsc28gZWxhYm9yYXRlcyBvbiBMb3JlbnpvJ3MgcG9pbnQg cmVnYXJkaW5nIGRpc2NvdmVyaW5nIG5laWdoYm9ycyBiYXNlZCBvbiBEQUQtTlMgcGFja2V0cy4N Cg0KVGhhbmtzLA0KSGVsZW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10g DQpTZW50OiBGcmlkYXksIEphbnVhcnkgMTAsIDIwMTQgNDo0NCBQTQ0KVG86IEpvZWwgSGFscGVy bjsgSW5nLVdoZXIgQ2hlbjsgSm9lbCBIYWxwZXJuOyBJbmctV2hlciBDaGVuDQpTdWJqZWN0OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhhbHBlcm4tNm1hbi1uZC1wcmUtcmVz b2x2ZS1hZGRyLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1oYWxwZXJu LTZtYW4tbmQtcHJlLXJlc29sdmUtYWRkci0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgSS4gQ2hlbiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoN Ck5hbWU6CQlkcmFmdC1oYWxwZXJuLTZtYW4tbmQtcHJlLXJlc29sdmUtYWRkcg0KUmV2aXNpb246 CTAwDQpUaXRsZToJCVRyaWdnZXJpbmcgTkQgQWRkcmVzcyBSZXNvbHV0aW9uIG9uIFJlY2Vpdmlu ZyBEQUQtTlMNCkRvY3VtZW50IGRhdGU6CTIwMTQtMDEtMTANCkdyb3VwOgkJSW5kaXZpZHVhbCBT dWJtaXNzaW9uDQpQYWdlczoJCTcNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1oYWxwZXJuLTZtYW4tbmQtcHJlLXJlc29sdmUtYWRkci0w MC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1oYWxwZXJuLTZtYW4tbmQtcHJlLXJlc29sdmUtYWRkci8NCkh0bWxpemVkOiAgICAgICBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oYWxwZXJuLTZtYW4tbmQtcHJlLXJlc29s dmUtYWRkci0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkcmFmdCBwcm9wb3NlcyBhIG5ldyBv cHRpb25hbCBldmVudCB0byB0cmlnZ2VyIGFkZHJlc3MNCiAgIHJlc29sdXRpb24gdXNpbmcgSVB2 NiBOZWlnaGJvciBEaXNjb3ZlcnkuICBUaGlzIGhlbHBzIG9wdGltaXplIHJvdXRlcg0KICAgcGVy Zm9ybWFuY2UsIGFuZCBjYW4gaGVscCBtaXRpZ2F0ZSBjZXJ0YWluIHBvdGVudGlhbCBORC1yZWxh dGVkDQogICBkZW5pYWwtb2Ytc2VydmljZSBhdHRhY2tzLiAgVXBvbiByZWNlaXZpbmcgYSBEQUQt TlMgbWVzc2FnZSwgdGhlDQogICBuZWlnaGJvciBzb2xpY2l0YXRpb24gbWVzc2FnZSB1c2VkIHRv IGRldGVjdCBkdXBsaWNhdGUgYWRkcmVzc2VzLCBpZg0KICAgdGhlIHRhcmdldCBhZGRyZXNzIGVu Y29kZWQgaW4gdGhlIERBRC1OUyBpcyBub3QgYSBkdXBsaWNhdGUgYWRkcmVzcywNCiAgIHRoZSBy ZWNlaXZpbmcgZGV2aWNlIHJlc3BvbmRzIGJ5IHRyaWdnZXJpbmcgYWRkcmVzcyByZXNvbHV0aW9u IGZvcg0KICAgdGhlIHRhcmdldCBhZGRyZXNzIGluIHRoZSBEQUQtTlMsIGluIHByZXBhcmF0aW9u IGZvciBleHBlY3RhbnQgZnV0dXJlDQogICBjb21tdW5pY2F0aW9uIHdpdGggdGhlIHNlbmRpbmcg ZGV2aWNlLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From ietf@rozanak.com Tue Jan 14 13:00: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 623781AE01C for ; Tue, 14 Jan 2014 13:00:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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-KplQLykhzq for ; Tue, 14 Jan 2014 13:00:39 -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 A25AF1ADF99 for ; Tue, 14 Jan 2014 13:00:38 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 461C123E24BF; Tue, 14 Jan 2014 21:00:26 +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 v4RXEEtEA64Z; Tue, 14 Jan 2014 22:00:24 +0100 (CET) Received: from kopoli (g226056222.adsl.alicedsl.de [92.226.56.222]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 69ADE23E24BC; Tue, 14 Jan 2014 22:00:24 +0100 (CET) From: "Hosnieh Rafiee" To: , "Sean J. Geoghegan" , "Erik Nordmark" , , "Christian Huitema" , "Tina TSOU" , "Michael Richardson" Subject: Call for adoption draft-rafiee-6man-ssas Date: Tue, 14 Jan 2014 22:00:21 +0100 Message-ID: <005801cf116b$a3d23930$eb76ab90$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8Ra6MMMl37hlbsReah4Xi5LrohHA== Content-Language: en-us Cc: 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, 14 Jan 2014 21:00:41 -0000 Hi, Is the any other issues that I need to address to forward with this document. I sent this message before Christmas. If there are more issues that I need to address, please feel free to share them Thank you, Smile, Hosnieh ------------------------ This version is corresponded to comments received by Dan, Tina, Michael, Tim, etc. Some of the changes: - the text is now clearer than before and I removed all confusing texts that I found. (if there is anything more just refer me to it) - Explained the purpose clearly (Especially for those who think that SSAS purpose is to also authorize routers without using RPKI, etc.. This is not true) - Separate the deploy ability version in a new document "local security" - Compared the network security with nodes' security (appendix) - revised the whole introduction There is also a new discussion list about authentication and authorization. We might come up with the use of this approach or combination with other approaches for a unique means of authentication. If you are interested, feel free to join https://www.ietf.org/mailman/listinfo/secauth For router authorization, this is the complement document of SSAS. http://tools.ietf.org/html/draft-rafiee-6man-local-security-00 . You can find also this document as one of the references of SSAS For CGA attacks, I am still waiting for the professors to answer me (They were quite busy recently and had less chance to take a look on my approaches). However, the attack is valid on sec value but we're thinking about optimizing the algorithm to fast executing this attack. I am trying to update this document, as well, as soon as I receive some feedbacks from these professors. Title: A Simple Secure Addressing Scheme for IPv6 AutoConfiguration (SSAS) URL: http://www.ietf.org/internet-drafts/draft-rafiee-6man-ssas-08.txt Status: http://datatracker.ietf.org/doc/draft-rafiee-6man-ssas Htmlized: http://tools.ietf.org/html/draft-rafiee-6man-ssas-08 Diff: http://www.ietf.org/rfcdiff?url2=draft-rafiee-6man-ssas-08 Abstract: The purpose of this document is to address the current problem inherent with using Cryptographically Generated Addresses (CGA) [RFC3972] and introduces a new algorithm that can eliminate the cost of CGA algorithm. This algorithm also responds to the security issues (IP spoofing) exists in Privacy Extension [RFC4941] or any other documents that does not focus on local security by integrating privacy with the security. If there are more comments, please share them. I'll be happy to apply them and improve the document. Thanks Smile, Hosnieh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From otroan@employees.org Wed Jan 15 00:03:35 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 835481AD6A4 for ; Wed, 15 Jan 2014 00:03:35 -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, 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 Pk97fsTz1yos for ; Wed, 15 Jan 2014 00:03:34 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 384BE1ADF4B for ; Wed, 15 Jan 2014 00:03:34 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAEtA1lKQ/khM/2dsb2JhbABagwu4foMOgRUWdIMlgT4uh2nDcBePB4MrgRMEkDeZfIMuOw X-IronPort-AV: E=Sophos;i="4.95,661,1384300800"; d="asc'?scan'208";a="2974768" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 15 Jan 2014 08:03:22 +0000 Received: from dhcp-10-61-98-100.cisco.com (dhcp-10-61-98-100.cisco.com [10.61.98.100]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0F82L1Q022239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Jan 2014 08:03:21 GMT From: Ole Troan Content-Type: multipart/signed; boundary="Apple-Mail=_F73CFC2B-4E59-456F-BDE2-1BF4F8CA0202"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: Conclusion: 6MAN Adoption call on draft-rafiee-6man-ssas-07 Date: Wed, 15 Jan 2014 09:03:21 +0100 Message-Id: <34A47FEE-22AF-4980-8A9A-4D0202CE1591@employees.org> To: 6man WG Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) 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: Wed, 15 Jan 2014 08:03:35 -0000 --Apple-Mail=_F73CFC2B-4E59-456F-BDE2-1BF4F8CA0202 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 All, Title: A Simple Secure Addressing Scheme for IPv6 = AutoConfiguration (SSAS) Draft: draft-rafiee-6man-ssas-07 Type: Working group Adoption call Last call: 2013-11-19 - 2013-11-26 (but in practice until now) Number of messages on thread: 75 Support for adoption: No consensus The chairs have after much deliberation and discussion with the AD, decided that there is no consensus to adopt the draft. This is based on the technical concerns raised during the adoption call, and the deployment situation of SEND. Issues have been raised regarding the proposed CGA algorithm that we don=92t see clear answers to. While we recognize that the problem of address spoofing and = authentication on IPv6 links is an important to solve, we do not see a consensus that = the proposed solution will significantly change the current SEND deployment = situation. We do not believe the working group understands why SEND is not = deployed. If that is because the users do not perceive the problem as important, or if other solutions (e.g. on L2) are being deployed. =20 Overall, we think these the technical and deployment issues need to be = addressed before the working group could adopt this document. We would encourage the working group to continue work on address = spoofing and authentication on IPv6 links. Best regards, Bob and Ole --Apple-Mail=_F73CFC2B-4E59-456F-BDE2-1BF4F8CA0202 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 iQEcBAEBCgAGBQJS1kDJAAoJEFuJXizso86gSa4H/jVQzZQsYDYrY+IO21iSG7Ok uFP4EG4lCDhW7hRxsixycrKzFmumdTwa60WbXyJckY4NHNmMSReWC3cVds10mtna +ToH/uaGQqW0aU6IAIL7gV1S0d5n5jq/hKsNemmtqO4a0tSFUhneKA+7l8tQjMdB FOw/IEmtDYWOu7oS+SmwsUVbM6xGjTDqVlE7NhE+WqCzE4sYqY9au3HvZ9+K2VXF PHeE5/EBNj7KhvzVEj2jP58QNwFfvb0go7Du2s0qZKSoHYnAUZ4zocNsL3icSL1U ng/273ZBRpSpLudoagF4wCRdTKoDZz6pRMHf9VcyCU1rM0CTJYCsgXvKCLGf6x0= =8V5Y -----END PGP SIGNATURE----- --Apple-Mail=_F73CFC2B-4E59-456F-BDE2-1BF4F8CA0202-- From alexandru.petrescu@gmail.com Wed Jan 15 07:25: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 9E4861AE37E for ; Wed, 15 Jan 2014 07:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, 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 1wBJytpWLeBK for ; Wed, 15 Jan 2014 07:25:29 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 178161AE3A8 for ; Wed, 15 Jan 2014 07:25:28 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s0FFPGqt015420 for ; Wed, 15 Jan 2014 16:25:16 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 18A472081D9 for ; Wed, 15 Jan 2014 16:26:27 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 108672081D0 for ; Wed, 15 Jan 2014 16:26:27 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0FFPD7c031057 for ; Wed, 15 Jan 2014 16:25:16 +0100 Message-ID: <52D6A859.1010407@gmail.com> Date: Wed, 15 Jan 2014 16:25:13 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Conclusion: 6MAN Adoption call on draft-rafiee-6man-ssas-07 References: <34A47FEE-22AF-4980-8A9A-4D0202CE1591@employees.org> In-Reply-To: <34A47FEE-22AF-4980-8A9A-4D0202CE1591@employees.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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, 15 Jan 2014 15:25:31 -0000 Le 15/01/2014 09:03, Ole Troan a écrit : > All, > > Title: A Simple Secure Addressing Scheme for IPv6 > AutoConfiguration (SSAS) Draft: draft-rafiee-6man-ssas-07 Type: > Working group Adoption call Last call: 2013-11-19 - 2013-11-26 (but > in practice until now) > > Number of messages on thread: 75 Support for adoption: No consensus > > The chairs have after much deliberation and discussion with the AD, > decided that there is no consensus to adopt the draft. This is based > on the technical concerns raised during the adoption call, and the > deployment situation of SEND. Issues have been raised regarding the > proposed CGA algorithm that we don’t see clear answers to. While we > recognize that the problem of address spoofing and authentication on > IPv6 links is an important to solve, we do not see a consensus that > the proposed solution will significantly change the current SEND > deployment situation. We do not believe the working group > understands why SEND is not deployed. If that is because the users do > not perceive the problem as important, or if other solutions (e.g. on > L2) are being deployed. The lack of SeND deployment could be an issue. There are some areas where IP security is needed with link scope, on links which have little or no link-layer security. One could also argue about the incompatibility of link1-layer security with link2-layer security; or maybe the optimizations which could exist if a wifi/bluetooth sensor node could carry a single set of keys instead of 2. To further dissect the question of SeND deployment one would need to quantify it. One would do so first by some simple means such as checking the availability of open-source implementations, and feature presence in linux and other kernels. Alex > > Overall, we think these the technical and deployment issues need to > be addressed before the working group could adopt this document. > > We would encourage the working group to continue work on address > spoofing and authentication on IPv6 links. > > Best regards, Bob and Ole > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From alexandru.petrescu@gmail.com Wed Jan 15 07: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 55A451AE0F7 for ; Wed, 15 Jan 2014 07:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, 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 At5Y2wTnuHRB for ; Wed, 15 Jan 2014 07:52:22 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 40A6A1ADFC9 for ; Wed, 15 Jan 2014 07:52:22 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s0FFq9D4024319 for ; Wed, 15 Jan 2014 16:52:09 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D0D8E2081C7 for ; Wed, 15 Jan 2014 16:53:19 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C817A200F53 for ; Wed, 15 Jan 2014 16:53:19 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0FFq94C018038 for ; Wed, 15 Jan 2014 16:52:09 +0100 Message-ID: <52D6AEA9.5070002@gmail.com> Date: Wed, 15 Jan 2014 16:52:09 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] References: <52C9D788.8060606@gmail.com> <52CFB51E.60501@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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, 15 Jan 2014 15:52:25 -0000 Hello, Just out of curiosity... below... Le 10/01/2014 11:57, Emmanuel Thierry a écrit : > Hello, > > Thanks for your answer. > > Le 10 janv. 2014 à 09:53, Alexandru Petrescu a écrit : > >> Hello, >> >> Thanks for the post. >> >> I could understand the need to spam block an entire /64 instead (a >> single line in a configuration file) rathern than 2^64 lines each >> telling an address in that file. >> >> Yes, this is relevant when writing other firewalling rules as >> well. >> >> In this sense it is good to have an 'overall' number - like a /64 >> - to designate one particular link and subnet. >> >> And one may like to use other such overall numbers such as a /65 >> or a /63 to designate these links. >> >> And yes, the privacy extensions RFC4941 makes that attacker may >> use that overall number /64 to generate addresses, and defender >> may need to use same number /64 to comfortably protect against it. >> A smarter attacker would use a /63 and a smarter defender too. > > Definitely. However, as an attacker, having a smaller prefix than a > IPv6 /64 to exploit for your attack could correspond in IPv4 to use > a smaller prefix than /32. I mean that as a defender, i would use > against an attacker who smartly uses its /63 or smaller, the same > techniques than an attacker who have access to an IPv4 /31 or > smaller: blacklist sequentially all IPv6 /64 that this attacker is > using. So anyway, a /64 boundary would at least help to leverage the > problem. > > This could also be a good hint to network operators or hosters. Some > virtual machine providers (for instance) divide their /64 into > smaller prefixes (i saw /96), When a virtual machine uses a /96 instead of a /64, is that prefix present in an RA? And, is there some address auto-configuration involved? (wondering about how is the Interface ID formed, because with Ethernet it must be 64bit long). (for example, in some non-Ethernet links - like IP/USB, or some IP/cellular - there are some particular non-documented mechanisms to form Interface IDs; but these are still 64bit length, never 22bit) Alex which may imply that a bad behavior > from one of their clients might influence other servers. I think > there should be a clear mention of the consequences it may have. > Such a mention may help to promote best practices (TODO: define best > practices). > > Best regards Emmanuel Thierry > > >> >> Le 09/01/2014 18:51, Emmanuel Thierry a écrit : >>> Hello, >>> >>> (first message on these lists, hope it is accurate) >>> >>> I'm generally thinking that the /64 limit helps to structure the >>> address space from the receiver point of view. Let's say i'm >>> running a mail server which tries to reduce spam by temporarily >>> blacklisting some senders. if i'm facing spammers who use their >>> IPv6 address space in a smart way, they will just have to >>> generate RFC 4941 addresses to exhaust a firewall memory. The >>> pragmatic way to face such attacks is to blacklist the whole >>> /64, never a unique /128. >>> >>> I don't know if it is to be considered as a best practice, but >>> for these reasons, as a receiver, i personally consider a /64 to >>> be assigned to a unique link, or at least a network managed by a >>> unique network administrator. Enforcing this limit in protocol >>> standards strengthen this assumption. This might be an >>> additional argument for the "please keep /64 for unique links". >>> >>> As a consequence, subdivide a /64 into several prefixes in order >>> to assign it on several networks might create a risk for devices >>> on one network to be blacklisted by actions performed by some >>> devices on another network, in case the whole /64 have been >>> blacklist by a "pragmatic" receiver. >>> >>> Best regards Emmanuel Thierry >>> >>> Le 5 janv. 2014 à 23:07, Brian E Carpenter a écrit : >>> >>>> Hi, >>>> >>>> A group of us put this together following a discussion some >>>> weeks ago on the v6ops list about the 64-bit boundary in IPv6 >>>> addresses. Discussion belongs in 6man, please. >>>> >>>> This draft is incomplete but we'd welcome input. Let me >>>> underline an important comment in the introduction: >>>> >>>> _The purpose of this document is to analyse the issues around >>>> this question. We make no proposal for change, but we do >>>> analyse the possible effects of a change._ >>>> >>>> >>>> Brian + co-authors >>>> >>>> -------- Original Message -------- Subject: I-D Action: >>>> draft-carpenter-6man-why64-00.txt Date: Sun, 05 Jan 2014 >>>> 13:59:17 -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-00.txt Pages : 14 Date : >>>> 2014-01-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-00 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -------------------------------------------------------------------- >>>> >>>> >>>> >> >>>> >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org Administrative Requests: >>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>> >>>> >>>> >>> >>>> >>>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >>> >> >> >> >>> >>> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >> >> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From ml@sekil.fr Wed Jan 15 08:40: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 AD1301AE10F for ; Wed, 15 Jan 2014 08:40:19 -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 dikfJSqdet2p for ; Wed, 15 Jan 2014 08:40:16 -0800 (PST) Received: from host1.ip6-networks.net (host1.ip6-networks.net [95.130.10.56]) by ietfa.amsl.com (Postfix) with ESMTP id B8B411AE0EE for ; Wed, 15 Jan 2014 08:40:15 -0800 (PST) Received: from [IPv6:2001:660:7301:3728:226:b0ff:fefa:237d] (unknown [IPv6:2001:660:7301:3728:226:b0ff:fefa:237d]) by host1.ip6-networks.net (Postfix) with ESMTPSA id 7ACF660A33; Wed, 15 Jan 2014 17:40:01 +0100 (CET) Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Emmanuel Thierry In-Reply-To: <52D6AEA9.5070002@gmail.com> Date: Wed, 15 Jan 2014 17:40:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <08A20B1D-7418-4343-AAE0-AF2535259CE4@sekil.fr> References: <52C9D788.8060606@gmail.com> <52CFB51E.60501@gmail.com> <52D6AEA9.5070002@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1085) 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, 15 Jan 2014 16:40:19 -0000 Hello, Le 15 janv. 2014 =E0 16:52, Alexandru Petrescu a =E9crit : > Hello, >=20 > Just out of curiosity... below... >=20 > Le 10/01/2014 11:57, Emmanuel Thierry a =E9crit : >> Hello, >>=20 >> Thanks for your answer. >>=20 >> Le 10 janv. 2014 =E0 09:53, Alexandru Petrescu a =E9crit : >>=20 >>> Hello, >>>=20 >>> Thanks for the post. >>>=20 >>> I could understand the need to spam block an entire /64 instead (a >>> single line in a configuration file) rathern than 2^64 lines each >>> telling an address in that file. >>>=20 >>> Yes, this is relevant when writing other firewalling rules as >>> well. >>>=20 >>> In this sense it is good to have an 'overall' number - like a /64 >>> - to designate one particular link and subnet. >>>=20 >>> And one may like to use other such overall numbers such as a /65 >>> or a /63 to designate these links. >>>=20 >>> And yes, the privacy extensions RFC4941 makes that attacker may >>> use that overall number /64 to generate addresses, and defender >>> may need to use same number /64 to comfortably protect against it. >>> A smarter attacker would use a /63 and a smarter defender too. >>=20 >> Definitely. However, as an attacker, having a smaller prefix than a >> IPv6 /64 to exploit for your attack could correspond in IPv4 to use >> a smaller prefix than /32. I mean that as a defender, i would use >> against an attacker who smartly uses its /63 or smaller, the same >> techniques than an attacker who have access to an IPv4 /31 or >> smaller: blacklist sequentially all IPv6 /64 that this attacker is >> using. So anyway, a /64 boundary would at least help to leverage the >> problem. >>=20 >> This could also be a good hint to network operators or hosters. Some >> virtual machine providers (for instance) divide their /64 into >> smaller prefixes (i saw /96), >=20 > When a virtual machine uses a /96 instead of a /64, is that prefix > present in an RA? About the hoster i think about, i didn't subscribe to their service (i = let you guess why ! ;)). However, their docs mention two major points: * How to calculate the IPv6: 2001:db8:1:XXX:XXX:XXX:XXX:YYYY/96 where = XXX:XXX:XXX:XXX is the IPv4 address (!!!) and YYYY is a number between = 0000 and FFFF * How to configure the IPv6: (...) in /etc/sysconfig/network add = "IPV6_AUTOCONF=3Dno" (...) So there is likely no RA on their network. It is quite common on hosters = networks. In France, i only knows OVH (IIRC) who sends Router = Advertisements on its network. In most of cases, server configuration is = performed by static manual configuration. Best regards Emmanuel Thierry > And, is there some address auto-configuration involved? (wondering > about how is the Interface ID formed, because with Ethernet it must be > 64bit long). >=20 > (for example, in some non-Ethernet links - like IP/USB, or some > IP/cellular - there are some particular non-documented mechanisms to > form Interface IDs; but these are still 64bit length, never 22bit) >=20 > Alex >=20 >=20 > which may imply that a bad behavior >> from one of their clients might influence other servers. I think >> there should be a clear mention of the consequences it may have. >> Such a mention may help to promote best practices (TODO: define best >> practices). >>=20 >> Best regards Emmanuel Thierry >>=20 >>=20 >>>=20 >>> Le 09/01/2014 18:51, Emmanuel Thierry a =E9crit : >>>> Hello, >>>>=20 >>>> (first message on these lists, hope it is accurate) >>>>=20 >>>> I'm generally thinking that the /64 limit helps to structure the >>>> address space from the receiver point of view. Let's say i'm >>>> running a mail server which tries to reduce spam by temporarily >>>> blacklisting some senders. if i'm facing spammers who use their >>>> IPv6 address space in a smart way, they will just have to >>>> generate RFC 4941 addresses to exhaust a firewall memory. The >>>> pragmatic way to face such attacks is to blacklist the whole >>>> /64, never a unique /128. >>>>=20 >>>> I don't know if it is to be considered as a best practice, but >>>> for these reasons, as a receiver, i personally consider a /64 to >>>> be assigned to a unique link, or at least a network managed by a >>>> unique network administrator. Enforcing this limit in protocol >>>> standards strengthen this assumption. This might be an >>>> additional argument for the "please keep /64 for unique links". >>>>=20 >>>> As a consequence, subdivide a /64 into several prefixes in order >>>> to assign it on several networks might create a risk for devices >>>> on one network to be blacklisted by actions performed by some >>>> devices on another network, in case the whole /64 have been >>>> blacklist by a "pragmatic" receiver. >>>>=20 >>>> Best regards Emmanuel Thierry >>>>=20 >>>> Le 5 janv. 2014 =E0 23:07, Brian E Carpenter a =E9crit : >>>>=20 >>>>> Hi, >>>>>=20 >>>>> A group of us put this together following a discussion some >>>>> weeks ago on the v6ops list about the 64-bit boundary in IPv6 >>>>> addresses. Discussion belongs in 6man, please. >>>>>=20 >>>>> This draft is incomplete but we'd welcome input. Let me >>>>> underline an important comment in the introduction: >>>>>=20 >>>>> _The purpose of this document is to analyse the issues around >>>>> this question. We make no proposal for change, but we do >>>>> analyse the possible effects of a change._ >>>>>=20 >>>>>=20 >>>>> Brian + co-authors >>>>>=20 >>>>> -------- Original Message -------- Subject: I-D Action: >>>>> draft-carpenter-6man-why64-00.txt Date: Sun, 05 Jan 2014 >>>>> 13:59:17 -0800 From: internet-drafts@ietf.org Reply-To: >>>>> internet-drafts@ietf.org To: i-d-announce@ietf.org >>>>>=20 >>>>>=20 >>>>> A New Internet-Draft is available from the on-line >>>>> Internet-Drafts directories. >>>>>=20 >>>>>=20 >>>>> 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-00.txt Pages : 14 Date : >>>>> 2014-01-05 >>>>>=20 >>>>> 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. >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-carpenter-6man-why64/ >>>>>=20 >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-carpenter-6man-why64-00 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> = -------------------------------------------------------------------- >>>>>=20 >>>>>=20 >>>>>=20 >>>=20 >>>>>=20 >>>>>=20 > IETF IPv6 working group mailing list >>>>> ipv6@ietf.org Administrative Requests: >>>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>>> = -------------------------------------------------------------------- >>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>>=20 > -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> = -------------------------------------------------------------------- >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>>=20 > -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >>>=20 >>>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >>=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From markzzzsmith@yahoo.com.au Wed Jan 15 22:42: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 A34B01AE1C3 for ; Wed, 15 Jan 2014 22:42:21 -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 i9rhlrpar95i for ; Wed, 15 Jan 2014 22:42:20 -0800 (PST) Received: from nm47.bullet.mail.ne1.yahoo.com (nm47.bullet.mail.ne1.yahoo.com [98.138.120.54]) by ietfa.amsl.com (Postfix) with ESMTP id 90F0C1AE021 for ; Wed, 15 Jan 2014 22:42:19 -0800 (PST) Received: from [127.0.0.1] by nm47.bullet.mail.ne1.yahoo.com with NNFMP; 16 Jan 2014 06:42:07 -0000 Received: from [98.138.101.130] by nm47.bullet.mail.ne1.yahoo.com with NNFMP; 16 Jan 2014 06:39:14 -0000 Received: from [66.196.81.172] by tm18.bullet.mail.ne1.yahoo.com with NNFMP; 16 Jan 2014 06:39:14 -0000 Received: from [98.139.212.231] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 16 Jan 2014 06:39:14 -0000 Received: from [127.0.0.1] by omp1040.mail.bf1.yahoo.com with NNFMP; 16 Jan 2014 06:39:14 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 548640.10386.bm@omp1040.mail.bf1.yahoo.com Received: (qmail 88443 invoked by uid 60001); 16 Jan 2014 06:39:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1389854354; bh=qzCG/fb7hsiBddAwbKWxKR/llssZeI3jEZsUsO7wh3Y=; 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=yjwZUfHMjUA0oyTz8gcaSjNzCZ6c3uDmFU7KKusETYm/Nxk1aamGUjKcbQpD2BPL4hzLRJA4VqnQW5b3fPQc+Sg7yyvhabzZhCv6deG0TMZU/2rhQYTOqEdetYGTF6Lk31InYH0kzQdTN2gV3qMKs2VD2D0pq5CqpSL7NcNoxeI= 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=54vJ2iaYFHh9a+9ddZTTtcbIahqANCgr8Al+Y/MlFIDCdSMXeCsmhzEhZft+Ol2eHlQPNxCpDeEMqkP55uwGObjNGlXQaObU3/7JX24YxE8YBq691SsQldoDFQ/asMp2YlP350PpEy9m8gL1kgUQgLrGPKm3wKynoBIYgW8Ngjs=; X-YMail-OSG: E.migRkVM1mXr2Bm9Y0BoQ0UiheCmqzb9hDkLXff2CKzJNG G74D9_otF_mn9FUkFlWv_BXPd1me_k9o3GNZwKFANR8TRhmCXyMI6UGd3q8U F0YwLKENjxXYShvnpDy1G1RxvrU.rRr2x3n3i6QqyssD_ZX_lbAJwWjHjwxo QbBdex.ZexIBkCmJ88Wb_booy0sOqUYpNnjuQ60Dx0jsVuYbEcmNEKygTyip VCMmIu0WtoHWpY5RA3WT65FbLevEq5yxsoDkYSdT7lfxmGLBi7NMqKubD_Ja Y8f95Njqe1Qs7zoZrQz1O7AeZbWiOJMJvQaaw_9KV8SYm5aNq16ZreIaEOSh zg1c.mn_FYe5PGuJ5V49.Cx2doX9yKguj0NInCnRz6Y5BsEc1ShlNJKqJUfy zadLyPQLIcGm1E9Ei.w.hKRoVE0NQevQHCh8BKEhNPiqiD8RRQnU4CtciOxy pZsOiZN6T8mszZG5hTW7F14mxxY0Z3odDxCa5amD6X_3NBqt037gn2YKqJai 3.YinMkgWyGfJXbNlrDFGsGegIqWqBLKaerrnmrE92tsC.JG7aKYih8O_ruF .gjbKn2A96.54kwARot4efyCLyHOUYN0X Received: from [121.200.231.211] by web161901.mail.bf1.yahoo.com via HTTP; Wed, 15 Jan 2014 22:39:14 PST X-Rocket-MIMEInfo: 002.001, SGksCgotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCgo.IEZyb206IEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20.Cj4gVG86IEFsZXhhbmRydSBQZXRyZXNjdSA8YWxleGFuZHJ1LnBldHJlc2N1QGdtYWlsLmNvbT4KPiBDYzogaXB2NkBpZXRmLm9yZwo.IFNlbnQ6IFRodXJzZGF5LCA5IEphbnVhcnkgMjAxNCA2OjE2IEFNCj4gU3ViamVjdDogUmU6IFtGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LWNhcnBlbnRlci02bWFuLXdoeTY0LTAwLnR4dF0KPiAKPiBFVUktNjQgY2EBMAEBAQE- X-Mailer: YahooMailWebService/0.8.173.622 References: <52C9D788.8060606@gmail.com> <1389041504.19037.YahooMailNeo@web161905.mail.bf1.yahoo.com> <52CD7A93.4030908@gmail.com> <52CDA427.80906@gmail.com> Message-ID: <1389854354.56698.YahooMailNeo@web161901.mail.bf1.yahoo.com> Date: Wed, 15 Jan 2014 22:39:14 -0800 (PST) From: Mark ZZZ Smith Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] To: Brian E Carpenter , Alexandru Petrescu In-Reply-To: <52CDA427.80906@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.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: Thu, 16 Jan 2014 06:42:21 -0000 Hi,=0A=0A----- Original Message -----=0A=0A> From: Brian E Carpenter =0A> To: Alexandru Petrescu =0A> Cc: ipv6@ietf.org=0A> Sent: Thursday, 9 January 2014 6:16 AM=0A>= Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt]=0A> =0A>= EUI-64 came first; it's used by Firewire and there was some expectation=0A= > that Firewire would become very important, or in general that EUI-64=0A> = would come to replace EUI-48.=0A> =0A> But maybe someone who has Christian'= s book could send a paraphrase=0A> of his explanation.=0A>=A0=0A=0AJust cat= ching up on the list, will do so if it hasn't already been done (actually d= ug it up to do off-list a week or so ago, but will do it on-list now).=0A= =0ARegards,=0AMark.=0A=0A=0A> Regards=0A> =A0 Brian=0A> =0A> On 09/01/2014= 05:19, Alexandru Petrescu wrote:=0A>> Le 06/01/2014 21:51, Mark ZZZ Smith= a =E9crit :=0A>>> Hi,=0A>>> =0A>>> I've had a quick read through, I thin= k this document would be quite=0A>>> useful.=0A>>> =0A>>> One thing I thi= nk would be good to capture is a bit of the=0A>>> history/rational behind = the choice of 64 IID.=0A>>> =0A>>> I became aware of that history via Chri= stian Huitema's "IPv6: =0A> The=0A>>> New Internet Protocol (2nd Edition)"= book, I think it would be =0A> good=0A>>> if that history was a bit more = widely available to explain and=0A>>> justify the choice.=0A>> =0A>> Hi,= =0A>> =0A>> I dont have the book handy, but I would be interested to learn= about how=0A>> this 64bit length came to life.=A0 I remember some discuss= ions of an =0A> 'h'=0A>> factor.=0A>> =0A>> I suppose IEEE's EUI-64 desig= n history is related, maybe because=0A>> triggered by same fear of address= space depletion (48bit identifiers);=0A>> knowing that one may see how wo= uld an EUI-128 influence in any way IPv6=0A>> addressing.=0A>> =0A>> Alex= =0A>> =0A>>> =0A>>> Regards, Mark.=0A>>> =0A>>> =0A>>> ----- Original Mes= sage -----=0A>>>> From: Brian E Carpenter To= : =0A> 6man=0A>>>> Cc: Sent: Monday, 6 January 2014 9:07 A= M =0A> Subject:=0A>>>> [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt= ]=0A>>>> =0A>>>> Hi,=0A>>>> =0A>>>> A group of us put this together follo= wing a discussion some weeks=0A>>>> ago on the v6ops list about the 64-bit= boundary in IPv6 addresses.=0A>>>> =A0 Discussion belongs in 6man, please.= =0A>>>> =0A>>>> This draft is incomplete but we'd welcome input. Let me = =0A> underline=0A>>>> an important comment in the introduction:=0A>>>> =0A= >>>> _The purpose of this document is to analyse the issues around this=0A= >>>> =A0 question.=A0 We make no proposal for change, but we do analyse the= =0A>>>> possible effects of a change._=0A>>>> =0A>>>> =0A>>>> Brian + co-= authors=0A>>>> =0A>>>> -------- Original Message -------- Subject: I-D Act= ion:=0A>>>> draft-carpenter-6man-why64-00.txt Date: Sun, 05 Jan 2014 13:59= :17=0A>>>> -0800 From: internet-drafts@ietf.org Reply-To:=0A>>>> internet= -drafts@ietf.org To: i-d-announce@ietf.org=0A>>>> =0A>>>> =0A>>>> A New In= ternet-Draft is available from the on-line Internet-Drafts=0A>>>> director= ies.=0A>>>> =0A>>>> =0A>>>> Title=A0 =A0 =A0 =A0 =A0 : Analysis of the 64= -bit Boundary in IPv6=0A>>>> Addressing Authors=A0 =A0 =A0 =A0 : Brian Ca= rpenter Tim Chown Fernando=0A>>>> Gont Sheng Jiang Alexandru Petrescu Andr= ew Yourtchenko Filename :=0A>>>> draft-carpenter-6man-why64-00.txt Pages= =A0 =A0 =A0 =A0 =A0 : 14 Date :=0A>>>> 2014-01-05=0A>>>> =0A>>>> Abstrac= t: The IPv6 unicast addressing format includes a separation=0A>>>> between= the prefix used to route packets to a subnet and the=0A>>>> interface ide= ntifier used to specify a given interface connected=0A>>>> to that subnet.= Historically the interface identifier has been=0A>>>> defined as 64 bits = long, leaving 64 bits for the prefix.=A0 This=0A>>>> document discusses th= e reasons for this fixed boundary and the=0A>>>> issues involved in treati= ng it as a variable boundary.=0A>>>> =0A>>>> =0A>>>> The IETF datatracker = status page for this draft is:=0A>>>> https://datatracker.ietf.org/doc/dra= ft-carpenter-6man-why64/=0A>>>> =0A>>>> There's also a htmlized version av= ailable at:=0A>>>> http://tools.ietf.org/html/draft-carpenter-6man-why64-0= 0=0A>>>> =0A>>>> =0A>>>> =0A>>>> =0A>>>> =0A>>>> =0A>>>> =0A>>>> =0A>>>> = =0A>>>> =0A> --------------------------------------------------------------= ------=0A>>>> =0A>>>> =0A>>>> =0A>>>> =0A>>>> =0A>> IETF IPv6 working grou= p mailing list=0A>>>> ipv6@ietf.org Administrative Requests:=0A>>>> https= ://www.ietf.org/mailman/listinfo/ipv6=0A> =0A>>>> =0A> --------------------= ------------------------------------------------=0A>>>> =0A>>> =0A>>>> =0A>= >>> =0A>>>> =0A>>>> =0A>> ------------------------------------------------= --------------------=0A>>> IETF IPv6 working group mailing list ipv6@ietf.= org Administrative=0A>>> Requests: https://www.ietf.org/mailman/listinfo/i= pv6=0A>>> ----------------------------------------------------------------= ----=0A>>> =0A>>> =0A>> =0A>> =0A>> --------------------------------------= ------------------------------=0A>> IETF IPv6 working group mailing list= =0A>> ipv6@ietf.org=0A>> Administrative Requests: https://www.ietf.org/ma= ilman/listinfo/ipv6=0A>> -------------------------------------------------= -------------------=0A>> =0A> =0A> ----------------------------------------= ----------------------------=0A> IETF IPv6 working group mailing list=0A> i= pv6@ietf.org=0A> Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6=0A> -------------------------------------------------------------= -------=0A> From otroan@employees.org Thu Jan 16 06:26: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 CCEE61AE35C for ; Thu, 16 Jan 2014 06:26:14 -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, 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 7iAgzLHsNzIJ for ; Thu, 16 Jan 2014 06:26:13 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 83D2A1AE349 for ; Thu, 16 Jan 2014 06:26:13 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAMvq11KQ/khL/2dsb2JhbABZgws4g1S4DYELFnSCT0sLGRQwAksUiBcNjAqbcZwxF45/gnY1gRQEkDqJGJBmgy47 X-IronPort-AV: E=Sophos;i="4.95,668,1384300800"; d="asc'?scan'208";a="3720756" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 16 Jan 2014 14:26:00 +0000 Received: from dhcp-10-61-100-137.cisco.com (dhcp-10-61-100-137.cisco.com [10.61.100.137]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0GEPxbk001825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Jan 2014 14:26:00 GMT From: Ole Troan Content-Type: multipart/signed; boundary="Apple-Mail=_279AD849-E704-45EC-8576-0F346E63DCE2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: WGLC: draft-ietf-6man-multicast-addr-arch-update-02 Date: Thu, 16 Jan 2014 15:25:59 +0100 Message-Id: <0F5F4D9B-A5BD-4D6A-9A9D-B8D912816E7A@employees.org> To: 6man WG Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) 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, 16 Jan 2014 14:26:15 -0000 --Apple-Mail=_279AD849-E704-45EC-8576-0F346E63DCE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All, This message starts a two week 6MAN Working Group Last Call on = draft-ietf-6man-multicast-addr-arch-update-02: Title : Updates to the IPv6 Multicast Addressing = Architecture Author(s) : M. Boucadair, S. Venaas Filename : draft-ietf-6man-multicast-addr-arch-update-02 Pages : 8 Date : 2013-10-18 = http://tools.ietf.org/html/draft-ietf-6man-multicast-addr-arch-update-02 as a Proposed Standard. Substantive comments and statements of support = for advancing this document should be directed to the mailing list. = Editorial suggestions can be sent to the authors. This last call will = end on January 30, 2014. Suresh Krishnan and JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = have volunteered to do a detailed review of the document. We would also = encourage volunteers to act as document shepherds. Please contact the = chairs directly. Regards, Bob Hinden & Ole Tr=C3=B8an --Apple-Mail=_279AD849-E704-45EC-8576-0F346E63DCE2 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 iQEcBAEBCgAGBQJS1+v3AAoJEFuJXizso86gyy4H/iX+MLjqGCvnHer/FUoyiJ9o 3tkxOjmeuUi4U68tpql0A2zXe8tKzpr1mqfI6ZrGzcQepyvyKdyBytwZj/arlmTQ jP1RRMvMHaqV9ruCsRe/aYdQIQDcD25qZg7lkS8C62sqfpyIKo9YGv+2Gj8G5sxs TtlnndygaMIABnY30W0cg1zyBmJqjkJPABAencITh1XL+ta76oJkWnG1M+R/dT8R NYlczz/voM02vrzPRDWf2DwhgGwUBInbP/8ajWibvtmTDNR0GAmJExmM3WyrD0nr O0piOGIRW6a828eOxj1SKIc002Rt7Y0rzHIfTe4sPzBQx7Mq63CtdOlveaVLSlk= =++Mu -----END PGP SIGNATURE----- --Apple-Mail=_279AD849-E704-45EC-8576-0F346E63DCE2-- From bob.hinden@gmail.com Thu Jan 16 06:41: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 9A3311AE356 for ; Thu, 16 Jan 2014 06:41:00 -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 s6wOwf1n6FVD for ; Thu, 16 Jan 2014 06:40:59 -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 027E81AE349 for ; Thu, 16 Jan 2014 06:40:58 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hi8so2316730wib.3 for ; Thu, 16 Jan 2014 06:40:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version; bh=XQ4NvrLQ7l+Qmmu5R6kOV57vkaicWffj0zoG15KxYOo=; b=eHblzs3ws2wA2yZ87/RX8RelUMFTtlODszhJJ4OASqWVu1DgiDm6tqEjiZit11FwHJ D5yzYzITXxg8cjcyDZI+ui4KadwQrG2JSR4nWiuMfBH2uXoM7rzz4IiGtp+qD1ZUlW+8 3XECBACx2vjQpYitmc5r+6+xWAaeE+Z6XF3N9X9u4HtT8lhyMb5ansGIvXhn3yBA/F8k khNvic3XJhEnJ0U4lZ9brl7wLMjswgPVOTIRpi3VQP+wGw0r8SdvmEr+0ucW3T5eiavl Uo2x68C9OLrth+j2CJ9+xd9aglH+XW/nC85rQRk5uyuXqbHTUL5E4AKEiqSBe7atAiNh B+0Q== X-Received: by 10.180.77.129 with SMTP id s1mr8320515wiw.56.1389883246423; Thu, 16 Jan 2014 06:40:46 -0800 (PST) Received: from ?IPv6:2601:9:4080:10:d0bb:31a1:7462:5ff5? ([2601:9:4080:10:d0bb:31a1:7462:5ff5]) by mx.google.com with ESMTPSA id e5sm6406677wja.15.2014.01.16.06.40.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Jan 2014 06:40:45 -0800 (PST) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_A6BD1C77-D70B-49C1-9016-8FCE0C4628C4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: 6MAN WG Last Call: Date: Thu, 16 Jan 2014 06:40:41 -0800 Message-Id: <5B4E67C2-3278-4D7D-A509-219CBEFE2589@gmail.com> To: IPv6 IPv6 List Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Cc: Bob Hinden 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, 16 Jan 2014 14:41:00 -0000 --Apple-Mail=_A6BD1C77-D70B-49C1-9016-8FCE0C4628C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 This message starts a two week 6MAN Working Group on advancing: Title: IPv6 Multicast Address Scopes Author(s): R. Droms Filename: draft-ietf-6man-multicast-scopes-02 Pages: 5 Date: 2013-11-11 http://tools.ietf.org/html/draft-ietf-6man-multicast-scopes-02 as a Proposed Standard. Substantive comments and statements of support = for advancing this document should be directed to the mailing list. = Editorial suggestions can be sent to the authors. This last call will = end on January 30th, 2014. Regards, Bob Hinden & Ole Tr=F8an --Apple-Mail=_A6BD1C77-D70B-49C1-9016-8FCE0C4628C4 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 iQEcBAEBCgAGBQJS1+9pAAoJEK7rdBF357uoygUIAJ0p7Yo/waE2qy0sS6TeC1vg +pUvL0bJA/7NpuKqs5BoaxUAKj5nt2X2nEPOAeDA/0ELjq59Ru486donsoI91COA X4gzOTA88wdSxs61g1N7aSzDYIjtwmWXPgteq22vmnty3mwiecZlcaqHE9ar2+dM y4YzOqWf0Hn9QQQqNDtZR7F9mLcSJPSvRNtqKuq51sC9w11EW5J4pOSmoYbFMO42 138sXh5hVZlAlL95SJ1UL/yx/CW9wIKB2Ykru9OBEHbwwvXT7ofFnwsT0dAEPc0+ bqS0FUCcu9FmZ6LKlQz7CRNG+RNlewA0YfaPHSRSXK8/d9aUUuRWtnIPYefILrk= =VAHz -----END PGP SIGNATURE----- --Apple-Mail=_A6BD1C77-D70B-49C1-9016-8FCE0C4628C4-- From ing-wher.chen@ericsson.com Thu Jan 16 08:43: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 E5E011AE0F7 for ; Thu, 16 Jan 2014 08:43: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_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 Ah-0wGJdaTBR for ; Thu, 16 Jan 2014 08:43:41 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 31A441ADFC9 for ; Thu, 16 Jan 2014 08:43:41 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-44-52d80c2dd752 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 4F.9E.23183.D2C08D25; Thu, 16 Jan 2014 17:43:26 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0347.000; Thu, 16 Jan 2014 11:43:28 -0500 From: Ing-Wher Chen To: "ipv6@ietf.org" Subject: FW: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-halpern-6man-nd-pre-resolve-addr-00 Thread-Topic: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-halpern-6man-nd-pre-resolve-addr-00 Thread-Index: AQHPEtZ7hOtWmJxCwEm98ozItqm05pqHji2Q Date: Thu, 16 Jan 2014 16:43:28 +0000 Message-ID: References: <20140116161745.24936.31951.idtracker@ietfa.amsl.com> In-Reply-To: <20140116161745.24936.31951.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyuXRPrK4ez40gg3NrmSxenn3P5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujO2/u1kK/nBVPF76lLmB8QZXFyMnh4SAiUTH5LvsELaYxIV7 69m6GLk4hASOMEpca1/KDuEsZ5RY0/qTDaSKTcBAYsPHLUwgtoiAssSM7nNgHcICExglupff YgFxRAQmMkpsXd3CBlFlJHHrZDPQKA4OFgFViWsTK0HCvALeEucXzwIrERJwlFhx/B6YzSng JLFx/mUWEJsR6KTvp9aALWMWEJe49WQ+E8SpAhJL9pxnhrBFJV4+/scKYStLfJ/ziAVkFbOA psT6XfoQrYoSU7ofskOsFZQ4OfMJywRG0VlIps5C6JiFpGMWko4FjCyrGDlKi1PLctONDDYx AgP/mASb7g7GPS8tDzFKc7AoifN+eescJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoEx5TKX 6LNN/1pu7Clj84yvq5h15hJD4eGlUnP9Z7AtkeHZM0uIKVaM5Vje5ZPV/3LYLMUM3xd8NP3x 5jKXWYikwcIrXY+1UhnUdjFkNVtN/HPju4FGeVdnqPoe7zo+zoUtZzWmSKe+q2d+ZZYocCrs 9ZLkaaonKuI+GYRGdwokbC59m3P9zw8lluKMREMt5qLiRAB38UV3SgIAAA== 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, 16 Jan 2014 16:43:43 -0000 QXMgcHJvbWlzZWQsIGJlbG93IGlzIHRoZSBJUFIgZGlzY2xvc3VyZSByZWxhdGVkIHRvDQpkcmFm dC1oYWxwZXJuLTZtYW4tbmQtcHJlLXJlc29sdmUtYWRkci0wMCAuDQoNClRoYW5rcywNCkhlbGVu DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJRVRGIFNlY3JldGFyaWF0IFtt YWlsdG86aWV0Zi1pcHJAaWV0Zi5vcmddIA0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMTYsIDIw MTQgODoxOCBBTQ0KVG86IEluZy1XaGVyIENoZW47IEpvZWwgSGFscGVybg0KQ2M6IGphcmkuYXJr a29AcGl1aGEubmV0OyBpcHItYW5ub3VuY2VAaWV0Zi5vcmcNClN1YmplY3Q6IElQUiBEaXNjbG9z dXJlOiBUZWxlZm9uYWt0aWVib2xhZ2V0IExNIEVyaWNzc29uIChwdWJsKSdzIFN0YXRlbWVudCBh Ym91dCBJUFIgcmVsYXRlZCB0byBkcmFmdC1oYWxwZXJuLTZtYW4tbmQtcHJlLXJlc29sdmUtYWRk ci0wMA0KDQoNCkRlYXIgSW5nLVdoZXIgQ2hlbiwgSm9lbCBIYWxwZXJuOg0KDQogQW4gSVBSIGRp c2Nsb3N1cmUgdGhhdCBwZXJ0YWlucyB0byB5b3VyIEludGVybmV0LURyYWZ0IGVudGl0bGVkICJU cmlnZ2VyaW5nIE5EIEFkZHJlc3MgUmVzb2x1dGlvbiBvbiBSZWNlaXZpbmcgREFELU5TIiAoZHJh ZnQtaGFscGVybi02bWFuLW5kLXByZS1yZXNvbHZlLWFkZHIpDQp3YXMgc3VibWl0dGVkIHRvIHRo ZSBJRVRGIFNlY3JldGFyaWF0IG9uIDIwMTQtMDEtMTYgYW5kIGhhcyBiZWVuIHBvc3RlZCBvbiB0 aGUgIklFVEYgUGFnZSBvZiBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIERpc2Nsb3N1cmVz Ig0KKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzIzMDAvKS4gVGhlIHRpdGxlIG9m IHRoZSBJUFIgZGlzY2xvc3VyZSBpcyAiVGVsZWZvbmFrdGllYm9sYWdldCBMTSBFcmljc3NvbiAo cHVibCkncyBTdGF0ZW1lbnQgYWJvdXQgSVBSIHJlbGF0ZWQgdG8gZHJhZnQtIGhhbHBlcm4tNm1h bi1uZC1wcmUtcmVzb2x2ZS1hZGRyLTAwLiIiKTsNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From ietf@rozanak.com Thu Jan 16 10:00: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 D0E231A1DFA; Thu, 16 Jan 2014 10:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 yligGnGwT29R; Thu, 16 Jan 2014 10:00:28 -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 6DF321A16F0; Thu, 16 Jan 2014 10:00:28 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 5F82E23E24BF; Thu, 16 Jan 2014 18:00:15 +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 0cFP6e1lrjGU; Thu, 16 Jan 2014 19:00:13 +0100 (CET) Received: from kopoli (g225113217.adsl.alicedsl.de [92.225.113.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id BC9EF23E24BC; Thu, 16 Jan 2014 19:00:13 +0100 (CET) From: "Hosnieh Rafiee" To: "IETF Chair" References: <34A47FEE-22AF-4980-8A9A-4D0202CE1591@employees.org> <52D6A859.1010407@gmail.com> In-Reply-To: <52D6A859.1010407@gmail.com> Subject: RE: Conclusion: 6MAN Adoption call on draft-rafiee-6man-ssas-07 Date: Thu, 16 Jan 2014 19:00:10 +0100 Message-ID: <010301cf12e4$ccbd8690$663893b0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJmpLcF3y5zH+S21udjEgCPzUyOIQKQYNcLmUP71CA= Content-Language: en-us Cc: brian@innovationslab.net, ipv6@ietf.org, 'Alexandru Petrescu' 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, 16 Jan 2014 18:00:31 -0000 I do not accept the chair arguments since this draft have its own = supporters in the mailing list and I do not see this decision a fair decision . We = all know that we need local security and I also discussed about how this = draft can help to faster deploy SeND . I addressed all the comments I received during the call and seriously cannot accept the result. http://tools.ietf.org/html/draft-rafiee-6man-local-security=20 -----------smile---------- Hosnieh =85 success is a journey, not a destination=85. You cannot change your destination overnight, but you can change your direction ... Focus on the journey > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Alexandru = Petrescu > Sent: Wednesday, January 15, 2014 4:25 PM > To: ipv6@ietf.org > Subject: Re: Conclusion: 6MAN Adoption call on = draft-rafiee-6man-ssas-07 >=20 > Le 15/01/2014 09:03, Ole Troan a =E9crit : > > All, > > > > Title: A Simple Secure Addressing Scheme for IPv6 > > AutoConfiguration (SSAS) Draft: draft-rafiee-6man-ssas-07 Type: > > Working group Adoption call Last call: 2013-11-19 - 2013-11-26 (but = in > > practice until now) > > > > Number of messages on thread: 75 Support for adoption: No consensus > > > > The chairs have after much deliberation and discussion with the AD, > > decided that there is no consensus to adopt the draft. This is based > > on the technical concerns raised during the adoption call, and the > > deployment situation of SEND. Issues have been raised regarding the > > proposed CGA algorithm that we don=92t see clear answers to. While = we > > recognize that the problem of address spoofing and authentication on > > IPv6 links is an important to solve, we do not see a consensus that > > the proposed solution will significantly change the current SEND > > deployment situation. We do not believe the working group = understands > > why SEND is not deployed. If that is because the users do not = perceive > > the problem as important, or if other solutions (e.g. on > > L2) are being deployed. >=20 > The lack of SeND deployment could be an issue. >=20 > There are some areas where IP security is needed with link scope, on = links > which have little or no link-layer security. >=20 > One could also argue about the incompatibility of link1-layer security with > link2-layer security; or maybe the optimizations which could exist if = a > wifi/bluetooth sensor node could carry a single set of keys instead of = 2. >=20 > To further dissect the question of SeND deployment one would need to > quantify it. One would do so first by some simple means such as = checking the > availability of open-source implementations, and feature presence in = linux > and other kernels. >=20 > Alex >=20 > > > > Overall, we think these the technical and deployment issues need to = be > > addressed before the working group could adopt this document. > > > > We would encourage the working group to continue work on address > > spoofing and authentication on IPv6 links. > > > > Best regards, Bob and Ole > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From swmike@swm.pp.se Thu Jan 16 11:02: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 DA28D1A1F66 for ; Thu, 16 Jan 2014 11:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.389 X-Spam-Level: X-Spam-Status: No, score=-4.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 PDesVc4COMJs for ; Thu, 16 Jan 2014 11:02:37 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5692F1A1F61 for ; Thu, 16 Jan 2014 11:02:29 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id EF4A09C; Thu, 16 Jan 2014 20:02:15 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E8E1A9A; Thu, 16 Jan 2014 20:02:15 +0100 (CET) Date: Thu, 16 Jan 2014 20:02:15 +0100 (CET) From: Mikael Abrahamsson To: Ing-Wher Chen Subject: Re: FW: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-halpern-6man-nd-pre-resolve-addr-00 In-Reply-To: Message-ID: References: <20140116161745.24936.31951.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "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, 16 Jan 2014 19:02:40 -0000 On Thu, 16 Jan 2014, Ing-Wher Chen wrote: > As promised, below is the IPR disclosure related to > draft-halpern-6man-nd-pre-resolve-addr-00 . What does "Reasonable and Non-Discriminatory License to All Implementers with Possible Royalty/Fee." mean? That doesn't sound like a defensive-only patent. -- Mikael Abrahamsson email: swmike@swm.pp.se From ing-wher.chen@ericsson.com Thu Jan 16 15:26: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 7D6571AD8F1 for ; Thu, 16 Jan 2014 15:26:14 -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 Twg8yRN1Ri7w for ; Thu, 16 Jan 2014 15:26:12 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id E64DC1AD8EE for ; Thu, 16 Jan 2014 15:26:11 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-8c-52d86a8458fd Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 70.34.23183.48A68D25; Fri, 17 Jan 2014 00:25:57 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0347.000; Thu, 16 Jan 2014 18:25:56 -0500 From: Ing-Wher Chen To: Mikael Abrahamsson Subject: RE: FW: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-halpern-6man-nd-pre-resolve-addr-00 Thread-Topic: FW: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-halpern-6man-nd-pre-resolve-addr-00 Thread-Index: AQHPEtZ7hOtWmJxCwEm98ozItqm05pqHji2QgAB66ID//+bJAA== Date: Thu, 16 Jan 2014 23:25:55 +0000 Message-ID: References: <20140116161745.24936.31951.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: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyuXRPiG5r1o0gg139rBYvz75nsni5dCub A5PHkiU/mTz+TnrIFMAUxWWTkpqTWZZapG+XwJXx5mwzc8FVxoqrF7qZGxhXMnYxcnJICJhI 3Pg7mxnCFpO4cG89WxcjF4eQwBFGienfu1kgnOWMEp0zb7OAVLEJGEhs+LiFCcQWEdCU2Lh9 AxuIzSygLHHn/kxGkAZhgSmMEm/XHgQbJSIwlVHixIaLQB0cQI6TRPPhLJAGFgFViWmLJoCt 5hXwlvh9YSHUtj2MEtsvXADbwCngLNFwCeI+RqD7vp9awwSxTVzi1pP5TBB3C0gs2XMe6gdR iZeP/7FC2MoS3+c8YoGo15FYsPsT1KXaEssWvoZaLChxcuYTlgmMYrOQjJ2FpGUWkpZZSFoW MLKsYuQoLU4ty003MtjECIyVYxJsujsY97y0PMQozcGiJM775a1zkJBAemJJanZqakFqUXxR aU5q8SFGJg5OqQbG3qvTfSaZMTv+lfx8WOgsr335oTM6AdmL6+Q7t0RIT+UJn+Uz5dz1G+tX /5qlclWFhTX6XbaSzoOu/q1fvpvO3rx24peMSM2c6Y9uPZHvOGP/+J3rdJ13kx5Ur7r2y2ZB 3+546028YjMuOucWrv3fUtN2QY45pHo2g9h9DbfG7G0n1uwTORL/WImlOCPRUIu5qDgRAESj CvZjAgAA 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, 16 Jan 2014 23:26:14 -0000 Mikael, I am not a lawyer. =20 So I can only point you to the IPR disclosure , which contains further contact information, and to RFC 3905. =20 Thanks, Helen From fernando@gont.com.ar Thu Jan 16 17:02: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 7F1931ACCE2 for ; Thu, 16 Jan 2014 17:02:37 -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 lfm-1_wnReEF for ; Thu, 16 Jan 2014 17:02:35 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 55B691AC441 for ; Thu, 16 Jan 2014 17:02:34 -0800 (PST) Received: from [2001:5c0:1000:a::29ff] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W3xpB-0000vh-Mv; Fri, 17 Jan 2014 02:02:17 +0100 Message-ID: <52D88115.5050506@gont.com.ar> Date: Thu, 16 Jan 2014 22:02:13 -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 , 6man WG Subject: On SEND deployment (Re: Conclusion: 6MAN Adoption call on draft-rafiee-6man-ssas-07) References: <34A47FEE-22AF-4980-8A9A-4D0202CE1591@employees.org> In-Reply-To: <34A47FEE-22AF-4980-8A9A-4D0202CE1591@employees.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Fri, 17 Jan 2014 01:02:37 -0000 Hi, Ole, [This is orthogonal to the consensus call from my pov, but felt like dropping a note] On 01/15/2014 05:03 AM, Ole Troan wrote: > We do not believe the working group understands why SEND is not > deployed. My two cents: * Use of trust anchors makes deployment painful for the general case. * Most popular OSes do not have a real SEND implementation (not long ago the only way to play on BSDs was a Java implementation?). When it comes to open source ones, the fact that SEND is IPR'ed doesn't help the situation. * While other parts of the "system" are largely unsecured, SeND probably does not much. (e.g, if a local attacker can spoof a DNS response, securing the layer-2/3 mapping will not buy much in most cases -- i.e., just spoof the DNS response, and you're done). * SEND wasn't there for v4. And there's a tendency to try to employ IPv6 as IPv4, focusing on the benefit of the larger address space (i.e., for some, "I lived with this in v4 for 20+ years, so..."). Not that I necessarily endorse this view, but just meant to spell it out. 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 gdaley@au.logicalis.com Thu Jan 16 18:14: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 F3D0E1ADBD0 for ; Thu, 16 Jan 2014 18:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.445 X-Spam-Level: X-Spam-Status: No, score=-1.445 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.538, 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 RwEego5YnJux for ; Thu, 16 Jan 2014 18:14:17 -0800 (PST) Received: from smtp1.au.logicalis.com (smtp1.au.logicalis.com [203.8.7.132]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC441AD84D for ; Thu, 16 Jan 2014 18:14:16 -0800 (PST) Received-SPF: None (smtp1.au.logicalis.com: no sender authenticity information available from domain of gdaley@au.logicalis.com) identity=mailfrom; client-ip=203.8.7.161; receiver=smtp1.au.logicalis.com; envelope-from="gdaley@au.logicalis.com"; x-sender="gdaley@au.logicalis.com"; x-conformance=spf_only Received-SPF: None (smtp1.au.logicalis.com: no sender authenticity information available from domain of postmaster@sdcexchht.au.logicalis.com) identity=helo; client-ip=203.8.7.161; receiver=smtp1.au.logicalis.com; envelope-from="gdaley@au.logicalis.com"; x-sender="postmaster@sdcexchht.au.logicalis.com"; x-conformance=spf_only Received: from unknown (HELO sdcexchht.au.logicalis.com) ([203.8.7.161]) by smtp1.au.logicalis.com with ESMTP; 17 Jan 2014 13:20:10 +1100 Received: from SDCEXCHMS.au.logicalis.com ([10.18.196.50]) by sdcexchht.au.logicalis.com ([fe80::68b7:8880:fefb:f742%12]) with mapi id 14.02.0347.000; Fri, 17 Jan 2014 13:14:01 +1100 From: Greg Daley To: 'Ing-Wher Chen' , "ipv6@ietf.org" Subject: RE: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt Thread-Topic: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt Thread-Index: AQHPDmY2hGYF66RRbk+N6Vv6p523J5qDMmwwgAATMeCABOYbYA== Date: Fri, 17 Jan 2014 02:14:01 +0000 Message-ID: <72381AF1F18BAE4F890A0813768D992817FCA84E@sdcexchms.au.logicalis.com> References: <20140111004402.10451.90724.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.196.183] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.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, 17 Jan 2014 02:14:20 -0000 Hi Helen, I've got a couple of issues with the draft apart from IPR. It seems that principal assumption is that off-link flooding can occur due = to sending packets to unknown host destinations on a subnet, and reuses the= mandatory DAD-NS transmission as a proof-of-life for an address to avoid p= ackets being transmitted on the link. Firstly, I think there could be simpler mitigation techniques for this: 1/ Mandate DHCP for global prefixes - which ensures that the devices send p= ackets to routers on the link to keep their address (and limit unregistered= address lookups) 2/ Treat on-link generated ND Cache entries (or entries which have previous= ly been REACHABLE) as different to off-link generated (rate limit). In that case, the ND resolution behaviour for incomplete off-link is reduce= d and live communications cannot be impacted. There is still a potential Do= S issue for initiating communications to quiet servers, but if the on-link = server has ever talked to the router it could still have a STALE NCE. Secondly, the proposal assumes that DAD-NS packets are visible to all devic= es on the link, whereas they aren't in a Multicast-snooped environment. This implicitly requires that the router is assigned to an all-multi interf= ace on the switch infrastructure, which it may be (but this isn't stated). = It also negates the general applicability of this to hosts (rather than ro= uters). Neighbour Solicitation messages for incomplete entries (per RFC 4861 S7.2.2= ) will be dropped by the snooping switches if there is no Multicast subscri= ber for the solicited nodes' multicast address. Not only is this a mitigat= ion of the potential attack, but also indicates an alternative for non-snoo= ping networks: 3/ Monitor the solicited nodes' addresses in the MLD querier router, and do= not transmit an NS from off-link for an incomplete address unless someone = is listening. So I guess my comment is that we have two other potential solutions for mit= igating transmission of off-link initiated NS's ( 1- Use DHCP bindings and = 3 - MLD Solicited Nodes'), and some fair ideas for mitigating resource chal= lenges in the ND engine (2), and decreased applicability in multicast snoop= environments. Can you tell us why we should use this encumbered solution? Sincerely,=20 Greg Daley gdaley@au.logicalis.com=20 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ing-Wher Chen Sent: Tuesday, 14 January 2014 9:53 AM To: ipv6@ietf.org Subject: RE: New Version Notification for draft-halpern-6man-nd-pre-resolve= -addr-00.txt Please note that we're actively working with Ericsson's legal department on= an IPR disclosure regarding the draft. Thanks, Helen -----Original Message----- From: Ing-Wher Chen=20 Sent: Monday, January 13, 2014 2:37 PM To: 'ipv6@ietf.org' Subject: FW: New Version Notification for draft-halpern-6man-nd-pre-resolve= -addr-00.txt Hello, The informational draft below documents Ericsson's solution, deployed since= early 2013, regarding Mikael's concern in the recent discussion about ND d= enial-of-service attacks. The draft also elaborates on Lorenzo's point reg= arding discovering neighbors based on DAD-NS packets. Thanks, Helen -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Friday, January 10, 2014 4:44 PM To: Joel Halpern; Ing-Wher Chen; Joel Halpern; Ing-Wher Chen Subject: New Version Notification for draft-halpern-6man-nd-pre-resolve-add= r-00.txt A new version of I-D, draft-halpern-6man-nd-pre-resolve-addr-00.txt has been successfully submitted by I. Chen and posted to the IETF repositor= y. Name: draft-halpern-6man-nd-pre-resolve-addr Revision: 00 Title: Triggering ND Address Resolution on Receiving DAD-NS Document date: 2014-01-10 Group: Individual Submission Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-halpern-6man-nd-p= re-resolve-addr-00.txt Status: https://datatracker.ietf.org/doc/draft-halpern-6man-nd-pre-= resolve-addr/ Htmlized: http://tools.ietf.org/html/draft-halpern-6man-nd-pre-resolv= e-addr-00 Abstract: This draft proposes a new optional event to trigger address resolution using IPv6 Neighbor Discovery. This helps optimize router performance, and can help mitigate certain potential ND-related denial-of-service attacks. Upon receiving a DAD-NS message, the neighbor solicitation message used to detect duplicate addresses, if the target address encoded in the DAD-NS is not a duplicate address, the receiving device responds by triggering address resolution for the target address in the DAD-NS, in preparation for expectant future communication with the sending device. = =20 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From huitema@microsoft.com Thu Jan 16 21:47: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 1F58C1ADF72 for ; Thu, 16 Jan 2014 21:47:51 -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 o5HK1_r7uvHr for ; Thu, 16 Jan 2014 21:47:49 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEA81ADF70 for ; Thu, 16 Jan 2014 21:47:48 -0800 (PST) Received: from BLUPR03CA036.namprd03.prod.outlook.com (10.141.30.29) by BLUPR03MB264.namprd03.prod.outlook.com (10.255.213.27) with Microsoft SMTP Server (TLS) id 15.0.847.13; Fri, 17 Jan 2014 05:47:36 +0000 Received: from BN1AFFO11FD044.protection.gbl (2a01:111:f400:7c10::119) by BLUPR03CA036.outlook.office365.com (2a01:111:e400:879::29) with Microsoft SMTP Server (TLS) id 15.0.842.7 via Frontend Transport; Fri, 17 Jan 2014 05:47:36 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD044.mail.protection.outlook.com (10.58.52.191) with Microsoft SMTP Server (TLS) id 15.0.847.12 via Frontend Transport; Fri, 17 Jan 2014 05:47:35 +0000 Received: from TK5EX14MBXC303.redmond.corp.microsoft.com ([169.254.3.123]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0158.002; Fri, 17 Jan 2014 05:47:08 +0000 From: Christian Huitema To: Brian E Carpenter , Alexandru Petrescu Subject: RE: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] Thread-Topic: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] Thread-Index: AQHPCmKCk/VLv06+1kmx10+1M16WD5p4LXEAgALYnICAADGQgIANPiQg Date: Fri, 17 Jan 2014 05:47:07 +0000 Message-ID: References: <52C9D788.8060606@gmail.com> <1389041504.19037.YahooMailNeo@web161905.mail.bf1.yahoo.com> <52CD7A93.4030908@gmail.com> <52CDA427.80906@gmail.com> In-Reply-To: <52CDA427.80906@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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)(779001)(679001)(689001)(2473001)(189002)(199002)(76482001)(74876001)(53806001)(93136001)(92726001)(6806004)(23676002)(56816005)(50986001)(76786001)(561944002)(92566001)(76796001)(4396001)(87936001)(93516002)(50466002)(74662001)(47446002)(54356001)(2656002)(80022001)(54316002)(49866001)(87266001)(90146001)(47976001)(77982001)(59766001)(85852003)(47736001)(83072002)(74706001)(81816001)(74502001)(81686001)(65816001)(66066001)(79102001)(31966008)(47776003)(77096001)(80976001)(69226001)(46102001)(85306002)(81342001)(83322001)(20776003)(55846006)(63696002)(33656001)(56776001)(44976005)(51856001)(74366001)(81542001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB264; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0094E3478A X-OriginatorOrg: microsoft.com 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, 17 Jan 2014 05:47:51 -0000 DQo+IEJ1dCBtYXliZSBzb21lb25lIHdobyBoYXMgQ2hyaXN0aWFuJ3MgYm9vayBjb3VsZCBzZW5k IGEgcGFyYXBocmFzZQ0KPiBvZiBoaXMgZXhwbGFuYXRpb24uDQoNCkkgaGF2ZSBvZiBjb3Vyc2Ug YSBmZXcgY29waWVzIG9uIG15IHNoZWx2ZXMuIE1hcmsgWlpaIFNtaXRoIGlzIHByb2JhYmx5IHJl ZmVycmluZyB0byB0aGUgQ2hhcHRlciA0IG9mICJJUHY2LCB0aGUgbmV3IEludGVybmV0IFByb3Rv Y29sLCIgd2hpY2ggd2FzIHB1Ymxpc2hlZCBpbiAxOTk2LiBUaGUgY2hhcHRlciBkZWFscyB3aXRo ICJwbHVnIGFuZCBwbGF5LCIgYW5kIHRoZSBmaXJzdCBwYXJhZ3JhcGggcmVhZHM6DQoNCiJCeSB0 aGUgZW5kIG9mIEp1bmUgMTk5NCwgdGhlIElQbmcgc2FnYSB3YXMgY29taW5nIHRvIGEgY2xvc2Uu IFRoZSBJUG5nIHNlbGVjdGlvbiBjb21taXR0ZWUgaGFkIGFsbW9zdCBtYWRlIHVwIGl0cycgbWlu ZC4gVGhlIGNob2ljZSBoYWQgdG8gYmUgYmFzZWQgb24gdGhlIFNJUFAgcHJvcG9zYWwsIGJ1dCBT SVBQIGNvdWxkIG5vdCBiZSBib3VnaHQgbG9jaywgc3RvY2ssIGFuZCBiYXJyZWwuIEEgc3Vic3Rh bnRpYWwgbnVtYmVyIG9mIGRpcmVjdG9yYXRlIG1lbWJlcnMgdGhvdWdodCB0aGF0IHRoZSA2NC1i aXQgYWRkcmVzc2VzIHdlcmUgdG9vIG5hcnJvdywgdGhhdCB0aGV5IHdvdWxkIG5vdCBwcm92aWRl IGVub3VnaCBmbGV4aWJpbGl0eSB0byBpbXBsZW1lbnQgcHJvcGVyIHJvdXRpbmcgcHJvdG9jb2xz LiBUaGVyZSB3YXMgYSBjb21wcm9taXNlIGluIHNpZ2h0LCBpZiBvbmx5IHRoZSBTSVBQIHByb3Bv bmVudHMgd291bGQgYWdyZWUgdG8gaW5jcmVhc2UgdGhlIGFkZHJlc3Mgc2l6ZSB0byAxMjggYml0 cy4gVGhlIElFVEYgZGVjaXNpb24gcHJvY2VzcyBpcyBiYXNlZCBvbiBidWlsZGluZyBjb25zZW5z dXMsIHBhcnQgb2Ygd2hpY2ggaW1wbGllcyBwb2xsaW5nIG9waW5pb24gbGVhZGVycy4gSSB3YXMg b25lIG9mIHRob3NlIGxlYWRlcnMgYnkgdGhpcyB0aW1lLCBvciBzbyB0aGV5IHRob3VnaHQsIHNv IHRoZXkgcG9sbGVkIG1lLiBXb3VsZCBJIGFjY2VwdCBpbmZsYXRpbmcgdGhlIGFkZHJlc3MgdG8g MTI4IGJpdHM/IEkgaGFkIHB1YmxpY2x5IHN0YXRlZCBtYW55IHRpbWVzIHRoYXQgNjQgYml0cyB3 YXMgbW9yZSB0aGFuIGVub3VnaCBhbmQgSSBjb3VsZCBiYWNrIG15IG9waW5pb24gd2l0aCBzdWJz dGFudGlhbCBtYXRoZW1hdGljYWwgYW5hbHlzaXMuIEhvd2V2ZXIsIEkgZGlkIG5vdCBoZXNpdGF0 ZSB0b28gbG9uZy4gR29pbmcgdG8gMTI4IGJpdHMgd2FzIGEgbGl0dGxlIHByaWNlIHRvIHBheSB0 byByZWFjaCBjb25zZW5zdXMgYW5kIHNhdmUgdGhlIEludGVybmV0LiBNb3Jlb3ZlciwgMTI4LWJp dCBhZGRyZXNzZXMgaGF2ZSBhIGRlZmluaXRlIGFkdmFudGFnZS4gVGhleSBoYXZlIHR3aWNlIHRo ZSB3aWR0aCB0aGF0IHJvdXRpbmcgcHJvY2VkdXJlcyByZXF1aXJlLCBoZW5jZSB0aGV5IG1ha2Ug YSBsb3Qgb2Ygcm9vbSBhdmFpbC1hYmxlIGZvciBwcm9wZXIgaW1wbGVtZW50YXRpb24gb2YgYXV0 byBjb25maWd1cmF0aW9uIHByb2NlZHVyZXMuICINCg0KSSB0aGVuIGdvIG9uIHRvIGV4cGxhaW4g aG93IGF1dG8gY29uZmlndXJhdGlvbiB3b3JrcyBieSBjb25jYXRlbmF0aW9uIG9mIGEgbmV0d29y ayBwcmVmaXggYW5kIGEgdW5pcXVlIGlkZW50aWZpZXIgb2YgdGhlIGhvc3QsIG5vcm1hbGx5IGEg TUFDIGFkZHJlc3MuIFRoZSAxOTk2IHZlcnNpb24gb2YgdGhlIGJvb2sgd2FzIHdyaXR0ZW4gYmVm b3JlIHRoZSBORCBzcGVjaWZpY2F0aW9ucyB3YXMgZmluYWxpemVkLCBhbmQgZG9lcyBub3QgYWN0 dWFsbHkgc3BlY2lmeSB0aGUgNjQgYml0IHByZWZpeCBzaXplLiBNYW55IGV4YW1wbGVzIHNob3cg YW4gODAgYml0IHByZWZpeCBhbmQgYSA0OCBiaXQgTUFDIGFkZHJlc3MuDQoNCi0tIENocmlzdGlh biBIdWl0ZW1hDQoNCg0K From ietf@rozanak.com Thu Jan 16 21:52: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 CA7BC1ADF78 for ; Thu, 16 Jan 2014 21:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 vIvaZvPW9HXq for ; Thu, 16 Jan 2014 21:52:49 -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 E91FE1ADF72 for ; Thu, 16 Jan 2014 21:52:48 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 374E123E24BF; Fri, 17 Jan 2014 05:52:35 +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 G116k1GSLJOa; Fri, 17 Jan 2014 06:52:34 +0100 (CET) Received: from kopoli (g225113217.adsl.alicedsl.de [92.225.113.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 1F1BC23E24BC; Fri, 17 Jan 2014 06:52:34 +0100 (CET) From: "Hosnieh Rafiee" To: "'Fernando Gont'" , "'Ole Troan'" , "'6man WG'" References: <34A47FEE-22AF-4980-8A9A-4D0202CE1591@employees.org> <52D88115.5050506@gont.com.ar> In-Reply-To: <52D88115.5050506@gont.com.ar> Subject: RE: On SEND deployment (Re: Conclusion: 6MAN Adoption call on draft-rafiee-6man-ssas-07) Date: Fri, 17 Jan 2014 06:52:31 +0100 Message-ID: <001201cf1348$50032470$f0096d50$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJmpLcF3y5zH+S21udjEgCPzUyOIQIAB5nYmUlFLxA= Content-Language: en-us 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: Fri, 17 Jan 2014 05:52:51 -0000 Fernando, > On 01/15/2014 05:03 AM, Ole Troan wrote: > > We do not believe the working group understands why SEND is not > > deployed. > > My two cents: > > * Use of trust anchors makes deployment painful for the general case. This is why I proposed a local centralized RPKI in the second draft. > * Most popular OSes do not have a real SEND implementation (not long ago > the only way to play on BSDs was a Java implementation?). When it comes to > open source ones, the fact that SEND is IPR'ed doesn't help the situation. The reason is because of CGA > * While other parts of the "system" are largely unsecured, SeND probably > does not much. (e.g, if a local attacker can spoof a DNS response, securing the > layer-2/3 mapping will not buy much in most cases -- i.e., just spoof the DNS > response, and you're done). I considered DNS spoofing to address that problem by proposing CGA-TSIG (it use both SSAS/CGA as its solution) and it is implemented. > * SEND wasn't there for v4. And there's a tendency to try to employ > IPv6 as IPv4, focusing on the benefit of the larger address space (i.e., for > some, "I lived with this in v4 for 20+ years, so..."). Not that I necessarily > endorse this view, but just meant to spell it out. Current available mechanism also have problem and cannot mitigate IP spoofing. This is the main reason I wrote that local security draft to address these problems. Hosnieh ---------- From swmike@swm.pp.se Thu Jan 16 23:39: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 54CF71ADFB6 for ; Thu, 16 Jan 2014 23:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.538, 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 IecngKfUVR7z for ; Thu, 16 Jan 2014 23:39:11 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id C40F41ADFB5 for ; Thu, 16 Jan 2014 23:39:10 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 682BD9C; Fri, 17 Jan 2014 08:38:57 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 616529A; Fri, 17 Jan 2014 08:38:57 +0100 (CET) Date: Fri, 17 Jan 2014 08:38:57 +0100 (CET) From: Mikael Abrahamsson To: Ing-Wher Chen Subject: RE: FW: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-halpern-6man-nd-pre-resolve-addr-00 In-Reply-To: Message-ID: References: <20140116161745.24936.31951.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "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, 17 Jan 2014 07:39:13 -0000 On Thu, 16 Jan 2014, Ing-Wher Chen wrote: > Mikael, > > I am not a lawyer. > > So I can only point you to the IPR disclosure , > which contains further contact information, and to RFC 3905. If I look at: https://datatracker.ietf.org/ipr/2235/ https://datatracker.ietf.org/ipr/2218/ Cisco and Juniper asserts that this is a defensive patent that normally is royalty-free to implementors. Ericsson makes no statement that this is the case for this patent which as far as I can see, is vital to implementing what is described in your draft. So what is your goal by submitting this informational draft? I'm not going to waste any time reviewing it if implementors can't implement it without paying money to Ericsson, because then we won't see wide adoption. Complete no-go for me. -- Mikael Abrahamsson email: swmike@swm.pp.se From otroan@employees.org Fri Jan 17 01:44: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 7FE7C1ADFB9 for ; Fri, 17 Jan 2014 01:44:06 -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, 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 pSYrqKilEuFp for ; Fri, 17 Jan 2014 01:44:05 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 295371ADFB6 for ; Fri, 17 Jan 2014 01:44:05 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAJFf2FKQ/khR/2dsb2JhbABZgwu8H4EPFnSCJQEBAQMBdwIFCxktC1cGiA8IxUEXjn8HgySBFASQOpl+gW+BPzs X-IronPort-AV: E=Sophos;i="4.95,670,1384300800"; d="asc'?scan'208";a="3761707" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 17 Jan 2014 09:43:52 +0000 Received: from dhcp-lys01-vla250-10-147-113-220.cisco.com (dhcp-lys01-vla250-10-147-113-220.cisco.com [10.147.113.220]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0H9hpKk013833 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 Jan 2014 09:43:51 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_CBC3F3EC-DDFC-4D44-A5CB-615898CCA569"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: MLD snooping of solicted-node multicast (Was: Re: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt From: Ole Troan In-Reply-To: <72381AF1F18BAE4F890A0813768D992817FCA84E@sdcexchms.au.logicalis.com> Date: Fri, 17 Jan 2014 10:43:50 +0100 Message-Id: <892FB91E-311D-4A50-A38B-4972F70847AB@employees.org> References: <20140111004402.10451.90724.idtracker@ietfa.amsl.com> <72381AF1F18BAE4F890A0813768D992817FCA84E@sdcexchms.au.logicalis.com> To: Greg Daley X-Mailer: Apple Mail (2.1827) Cc: 6man WG , Ing-Wher Chen 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, 17 Jan 2014 09:44:06 -0000 --Apple-Mail=_CBC3F3EC-DDFC-4D44-A5CB-615898CCA569 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greg, sorry to divert your thread. > Neighbour Solicitation messages for incomplete entries (per RFC 4861 = S7.2.2) will be dropped by the snooping switches if there is no = Multicast subscriber for the solicited nodes' multicast address. Not = only is this a mitigation of the potential attack, but also indicates an = alternative for non-snooping networks: I hear that MLD snooping for the solicited-node multicast groups isn't = supported in most (if not all) switches. partly because MLD snooping doesn't work well, but also because it = becomes very costly to support state for this many multicast groups. anyone with differing experience? cheers, Ole --Apple-Mail=_CBC3F3EC-DDFC-4D44-A5CB-615898CCA569 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 iQEcBAEBCgAGBQJS2PtWAAoJEFuJXizso86gSasIAIC8tWnAdmUHm6MLSAXskWuj DfIJ/gnYvfLQGC8kGMfPcEkYRoMeNU66mIDWFKwf8OjqYRX/sdiqY4mc0/Dk2JoV J6gUAv9kMNHsD7wm1CdhXGPXJZrDFE3cJz/acPr4rpQpp6FoMskqVBMlqPde/MFi Kf2wulg00DOrwsV7lQ3uG78UmMJziAwhfEJg1P18m570rOrZ0UcevmKQ4LMZyTsJ 28RI3z+S7nbwO9O3FlWvuv9bLt3Dbiale9i/wT98QUsv2aHpB5p3umw8AZQjCjqV mXw63mxIfILIS8apFWNWggppVNc2gE2DxZ00n4jM/qb0bb7QoptiM0JBTUGqXdo= =RIl4 -----END PGP SIGNATURE----- --Apple-Mail=_CBC3F3EC-DDFC-4D44-A5CB-615898CCA569-- From lorenzo@google.com Fri Jan 17 01:49: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 27F7B1ADFBA for ; Fri, 17 Jan 2014 01:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, 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 4Gz4x_s7I4L8 for ; Fri, 17 Jan 2014 01:49:12 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B69301ADFB6 for ; Fri, 17 Jan 2014 01:49:12 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id e14so5030538iej.4 for ; Fri, 17 Jan 2014 01:49:00 -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=XGC+jUkat1AKeLkVeo7eILbAho5z8COTN72s7RnhHTk=; b=iXt4FTCZBsj486RhUFgVJBodkDpEvqb/8fqpDrV767H6UfaFOi2M4Ab+xPvckyhpt6 ApQhdS8LDtWR8Or7vFRxqCxghfADekYuaZ4TTn4+/XYax3ENr64Q4Dv5zDzsXST/doWx HNqW19QqXyrU8aAw6VG0LD18W6GJLFslmL4SfXjouC7oG4BuNJlj9/rO17QczP3g0vXF S8ceJO1RiiQCU08gwITgP7lTrxH2ONJ0K1BrnSqSmCAv22neAenanRC12j8D6C3Ob+Vq oJgrDyDypUZu0Akl77cKGit2euyDey4Dr+EfacAv8vLCdjWkxmmFyeb/+tGf40p0HfIU wC1A== 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=XGC+jUkat1AKeLkVeo7eILbAho5z8COTN72s7RnhHTk=; b=Z8moLKpas4doAwR9ahHcIzVWVIyWqSc4TRTDm2yURdo8x+VmbuxaSYhDHbVBlB/OBs 0WZjHEZvVZmBWCHbBWxqBYLM3Qb/ZPKvF0mSuvEph8ygjayRBUrmN6dtH2cEMDOXklAY AjUrusEHiK5WSvGxuq1wkASy9hRxh7L8/PYUXj+ZmbxIUjXjZEDf9SNbk/jlRE5STBLy 31F3JZoZ9kgXt32+9vnaTk1yQaXBpMHqmQZOODZvn0ZsDWnBEyzLejCOcObcantAqBuj OPxdhvJGIe4Yd5OA4oQfl3FpPOgDpmxs4FGM+0dIjk2rzIf2+zcDZaOWwTdu5g1rMp3y ud9g== X-Gm-Message-State: ALoCoQnSSJ9hnruTRInhUgR/KeAnLTGsNyBUq2Y7G0S1chgyYjP/NBVpeS/QGDAsT4VzUj7NkEt2d5UVTrcEHQkK5jqFWm5NrVO2lJ7p0NBAduf6/VR7wiTB7e2UC6g7l2JRULykdnk/Zb8kra3wqvnH0sdFQP0pishjOnHzuJBEuEoV3zM0IzDxCReOLwWYEVGJKssar4hj X-Received: by 10.50.79.228 with SMTP id m4mr1658616igx.47.1389952140077; Fri, 17 Jan 2014 01:49:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Fri, 17 Jan 2014 01:48:39 -0800 (PST) In-Reply-To: <892FB91E-311D-4A50-A38B-4972F70847AB@employees.org> References: <20140111004402.10451.90724.idtracker@ietfa.amsl.com> <72381AF1F18BAE4F890A0813768D992817FCA84E@sdcexchms.au.logicalis.com> <892FB91E-311D-4A50-A38B-4972F70847AB@employees.org> From: Lorenzo Colitti Date: Fri, 17 Jan 2014 01:48:39 -0800 Message-ID: Subject: Re: MLD snooping of solicted-node multicast (Was: Re: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt To: Ole Troan Content-Type: multipart/alternative; boundary=089e013a1f16908dc504f027738c Cc: Ing-Wher Chen , 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, 17 Jan 2014 09:49:14 -0000 --089e013a1f16908dc504f027738c Content-Type: text/plain; charset=UTF-8 On Fri, Jan 17, 2014 at 1:43 AM, Ole Troan wrote: > I hear that MLD snooping for the solicited-node multicast groups isn't > supported in most (if not all) switches. > partly because MLD snooping doesn't work well, but also because it becomes > very costly to support state for this many multicast groups. > On wifi networks, I don't see why that would be. There are basically two solicited-node groups per host, and wifi access points already track lots of state on a per-MAC address basis. --089e013a1f16908dc504f027738c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 17, 2014 at 1:43 AM, Ole Troan <otroan@employees.org> wrote:
I hear that MLD snooping for the solicited-n= ode multicast groups isn't supported in most (if not all) switches.
partly because MLD snooping doesn't work well, but also because it beco= mes very costly to support state for this many multicast groups.

On wifi networks, I don't see why that would = be. There are basically two solicited-node groups per host, and wifi access= points already track lots of state on a per-MAC address basis.
--089e013a1f16908dc504f027738c-- From tjc@ecs.soton.ac.uk Fri Jan 17 05:39: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 DE0531AE0B9 for ; Fri, 17 Jan 2014 05:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 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.538, SPF_NEUTRAL=0.779] 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 gHlvR604MxGv for ; Fri, 17 Jan 2014 05:38:58 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 9363E1ADF60 for ; Fri, 17 Jan 2014 05:38:58 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s0HDc8tM028880; Fri, 17 Jan 2014 13:38:08 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s0HDc8tM028880 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1389965889; bh=DF9HFkXIHZuYnVbR2cb0IkJKZS8=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=OoxMglUa9JWy1pzQMppSrBJkkMO1aV6tCraHald7r6sLDQbzdjLicMBHAASn2NciV 4m/J01kLeQUN7jvflxxKwE19LEvfkXC8SmOr9Rwk7RWkkt/RGWbaaDV5zfkNC0CRyK 7kdntFDN0rcK75mB4gPuGJHtw+2yj53LcDFro0sI= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q0GDc80959608839YA ret-id none; Fri, 17 Jan 2014 13:38:09 +0000 Received: from dhcp-163-20.wireless.soton.ac.uk (dhcp-163-20.wireless.soton.ac.uk [152.78.163.20] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s0HDc4Hx027137 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 Jan 2014 13:38:04 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: MLD snooping of solicted-node multicast (Was: Re: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt From: Tim Chown In-Reply-To: <892FB91E-311D-4A50-A38B-4972F70847AB@employees.org> Date: Fri, 17 Jan 2014 13:38:06 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140111004402.10451.90724.idtracker@ietfa.amsl.com> <72381AF1F18BAE4F890A0813768D992817FCA84E@sdcexchms.au.logicalis.com> <892FB91E-311D-4A50-A38B-4972F70847AB@employees.org> <5DC8FA82-DD79-49F5-8842-0243CDF77B7D@ecs.soton.ac.uk> To: Ole Troan X-Mailer: Apple Mail (2.1510) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q0GDc8095960883900; tid=q0GDc80959608839YA; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s0HDc8tM028880 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: Ing-Wher Chen , 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, 17 Jan 2014 13:39:01 -0000 On 17 Jan 2014, at 09:43, Ole Troan wrote: > Greg, sorry to divert your thread. >=20 >> Neighbour Solicitation messages for incomplete entries (per RFC 4861 = S7.2.2) will be dropped by the snooping switches if there is no = Multicast subscriber for the solicited nodes' multicast address. Not = only is this a mitigation of the potential attack, but also indicates an = alternative for non-snooping networks: >=20 > I hear that MLD snooping for the solicited-node multicast groups isn't = supported in most (if not all) switches. > partly because MLD snooping doesn't work well, but also because it = becomes very costly to support state for this many multicast groups. >=20 > anyone with differing experience? Well, MLD snooping seems very prone to bugs. We have an open case = currently with a particular vendor which means if we enable MLD snooping = (which is beneficial given we have several multicast IPv6 TV channels) = the devices will get a little 'enthusiastic' and filter all RAs. We = have had at least one similar case in the past. I guess use of MLD = snooping in enterprise networks is relatively rare though. Tim= From fgont@si6networks.com Fri Jan 17 05:48: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 E08BC1AE0C4 for ; Fri, 17 Jan 2014 05:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.31 X-Spam-Level: X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, 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 ni0QsnRs-kGD for ; Fri, 17 Jan 2014 05:48: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 D1EC51AE0BD for ; Fri, 17 Jan 2014 05:48:14 -0800 (PST) Received: from 30-154-16-190.fibertel.com.ar ([190.16.154.30] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W49m8-0003WE-23; Fri, 17 Jan 2014 14:47:56 +0100 Message-ID: <52D90272.30604@si6networks.com> Date: Fri, 17 Jan 2014 07:14:10 -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: Hosnieh Rafiee , 'Fernando Gont' , 'Ole Troan' , '6man WG' Subject: Re: On SEND deployment (Re: Conclusion: 6MAN Adoption call on draft-rafiee-6man-ssas-07) References: <34A47FEE-22AF-4980-8A9A-4D0202CE1591@employees.org> <52D88115.5050506@gont.com.ar> <001201cf1348$50032470$f0096d50$@rozanak.com> In-Reply-To: <001201cf1348$50032470$f0096d50$@rozanak.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Fri, 17 Jan 2014 13:48:17 -0000 Hosnieh, On 01/17/2014 02:52 AM, Hosnieh Rafiee wrote: >> My two cents: >> >> * Use of trust anchors makes deployment painful for the general case. > > This is why I proposed a local centralized RPKI in the second draft. What do you mean by "local centralized"? Whether the PKI is local or global doesn't seem to affect how hard this is to deploy. >> * Most popular OSes do not have a real SEND implementation (not long ago >> the only way to play on BSDs was a Java implementation?). When it comes to >> open source ones, the fact that SEND is IPR'ed doesn't help the situation. > > The reason is because of CGA IIRC, there were *two* patents on SEND. >> * While other parts of the "system" are largely unsecured, SeND probably >> does not much. (e.g, if a local attacker can spoof a DNS response, > securing the >> layer-2/3 mapping will not buy much in most cases -- i.e., just spoof the > DNS >> response, and you're done). > > I considered DNS spoofing to address that problem by proposing CGA-TSIG (it > use both SSAS/CGA as its solution) and it is implemented. I didn't go through your I-D in detail, hence I cannot comment one way or another. Based on the discussions it seems folks are not convinced why this would be easier to deploy than send. So if you're willing to continue pursuing this effort, you could try to spell out the reasons for which SEND has not been widely deployed, and provide a clear explanation on why your proposal would make a difference. -- Feel free to start from the reasons I provided, or tweak as deemed necessary. >> * SEND wasn't there for v4. And there's a tendency to try to employ >> IPv6 as IPv4, focusing on the benefit of the larger address space (i.e., > for >> some, "I lived with this in v4 for 20+ years, so..."). Not that I > necessarily >> endorse this view, but just meant to spell it out. > > Current available mechanism also have problem and cannot mitigate IP > spoofing. This is the main reason I wrote that local security draft to > address these problems. Agreed. But we're analyzing why SEND has not been widely deployed. If folks out there do not consider this is to be a problem that is worth addressing, no matter what solution we propose, it will still be a "problem not worth addressing" from their point of view. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From christopher.morrow@gmail.com Fri Jan 17 07:21: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 5104E1AE12D for ; Fri, 17 Jan 2014 07:21:02 -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 77OZejkLFz-I for ; Fri, 17 Jan 2014 07:20:59 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 243F81AE143 for ; Fri, 17 Jan 2014 07:20:58 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id ec20so3664960lab.23 for ; Fri, 17 Jan 2014 07:20:45 -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=6fNxQ2wBl0t0tEJnEE20rhLGI8MnC2dbHjt/lpb1baI=; b=d22PbxB6QWFJ3EhwpKXdtqBlEdGju/Tla2v+h+xKxUK0BEXquSlJujVWB7KVcI5gRc ExvWe8bbxGAnK+1gFThNOcqYyFCgNEad1BY0uBak5SiyKMIdPDQqKiEbG725LxkkB3mI 6ApNyXeuZkvSkY3z8fXfl0VoW9gG3q1SXHYXgsjDm6ywP6PhyBMBHCPwUYezgCTs/32q 1TI/0ovuZocgIUMLdWu47hkszXsayTAAfw2eSQO0MsBJKYWmYxCI7n7SzzwD+hxXdAm1 9rYJHbzROnlx96tL7gs4+EgbpJMJHNGEved1IwvZe9sFxyEl0X9tLBXUPg7+uLAvUSDx 2Phg== MIME-Version: 1.0 X-Received: by 10.112.148.104 with SMTP id tr8mr1309768lbb.42.1389972045771; Fri, 17 Jan 2014 07:20:45 -0800 (PST) Received: by 10.152.37.170 with HTTP; Fri, 17 Jan 2014 07:20:45 -0800 (PST) In-Reply-To: References: <20140116161745.24936.31951.idtracker@ietfa.amsl.com> Date: Fri, 17 Jan 2014 10:20:45 -0500 Message-ID: Subject: Re: FW: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-halpern-6man-nd-pre-resolve-addr-00 From: Christopher Morrow To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Cc: "ipv6@ietf.org" , Ing-Wher Chen 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, 17 Jan 2014 15:21:02 -0000 it kind of sounds like the 'with Possible Royalty/Fee' part means ericsson just doesn't want wide adoption. (or rather they do, so they can capitalize it...) On Fri, Jan 17, 2014 at 2:38 AM, Mikael Abrahamsson wrote: > On Thu, 16 Jan 2014, Ing-Wher Chen wrote: > >> Mikael, >> >> I am not a lawyer. >> >> So I can only point you to the IPR disclosure >> , >> which contains further contact information, and to RFC 3905. > > > If I look at: > > https://datatracker.ietf.org/ipr/2235/ > https://datatracker.ietf.org/ipr/2218/ > > Cisco and Juniper asserts that this is a defensive patent that normally is > royalty-free to implementors. > > Ericsson makes no statement that this is the case for this patent which as > far as I can see, is vital to implementing what is described in your draft. > > So what is your goal by submitting this informational draft? I'm not going > to waste any time reviewing it if implementors can't implement it without > paying money to Ericsson, because then we won't see wide adoption. Complete > no-go for me. > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From jmh@joelhalpern.com Fri Jan 17 07:43: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 22F631AE10D for ; Fri, 17 Jan 2014 07:43:20 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 8diL_ek2uXtP for ; Fri, 17 Jan 2014 07:43:18 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id F075D1AE0AA for ; Fri, 17 Jan 2014 07:43:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id CC3771D262D; Fri, 17 Jan 2014 07:43:05 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-128.clppva.east.verizon.net [70.106.135.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 8FB791C0C57; Fri, 17 Jan 2014 07:43:04 -0800 (PST) Message-ID: <52D94F86.3040601@joelhalpern.com> Date: Fri, 17 Jan 2014 10:43:02 -0500 From: "Joel M. Halpern" 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: Greg Daley , 'Ing-Wher Chen' , "ipv6@ietf.org" Subject: Re: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt References: <20140111004402.10451.90724.idtracker@ietfa.amsl.com> <72381AF1F18BAE4F890A0813768D992817FCA84E@sdcexchms.au.logicalis.com> In-Reply-To: <72381AF1F18BAE4F890A0813768D992817FCA84E@sdcexchms.au.logicalis.com> 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: Fri, 17 Jan 2014 15:43:20 -0000 Let me see if I can help a bit. Firstly, we are trying for something that works with the existing specified Ipv6 deployments. So mandating DHCP, and DHCP-guard, was not a choice we felt we could take. Using DHCP, dhcp-guard, and dhcp derived mechanisms to fill the router table is indeed a viable alternative for operators who wish to run their networks that way. Secondly, we are specifically concerned with the off-link based denial of service attack. Where the attack attempts to fill either the link (hard) or the router cache in such a way as to interfere with legitimate address resolution and communication. The use of multicast by IPv6 ND is understood and assumed. It does not help when the router is the target of the external attack. Yours, Joel On 1/16/14 9:14 PM, Greg Daley wrote: > Hi Helen, > > I've got a couple of issues with the draft apart from IPR. > > It seems that principal assumption is that off-link flooding can occur due to sending packets to unknown host destinations on a subnet, and reuses the mandatory DAD-NS transmission as a proof-of-life for an address to avoid packets being transmitted on the link. > > Firstly, I think there could be simpler mitigation techniques for this: > 1/ Mandate DHCP for global prefixes - which ensures that the devices send packets to routers on the link to keep their address (and limit unregistered address lookups) > 2/ Treat on-link generated ND Cache entries (or entries which have previously been REACHABLE) as different to off-link generated (rate limit). > > In that case, the ND resolution behaviour for incomplete off-link is reduced and live communications cannot be impacted. There is still a potential DoS issue for initiating communications to quiet servers, but if the on-link server has ever talked to the router it could still have a STALE NCE. > > Secondly, the proposal assumes that DAD-NS packets are visible to all devices on the link, whereas they aren't in a Multicast-snooped environment. > > This implicitly requires that the router is assigned to an all-multi interface on the switch infrastructure, which it may be (but this isn't stated). It also negates the general applicability of this to hosts (rather than routers). > > Neighbour Solicitation messages for incomplete entries (per RFC 4861 S7.2.2) will be dropped by the snooping switches if there is no Multicast subscriber for the solicited nodes' multicast address. Not only is this a mitigation of the potential attack, but also indicates an alternative for non-snooping networks: > > 3/ Monitor the solicited nodes' addresses in the MLD querier router, and do not transmit an NS from off-link for an incomplete address unless someone is listening. > > > So I guess my comment is that we have two other potential solutions for mitigating transmission of off-link initiated NS's ( 1- Use DHCP bindings and 3 - MLD Solicited Nodes'), and some fair ideas for mitigating resource challenges in the ND engine (2), and decreased applicability in multicast snoop environments. > > Can you tell us why we should use this encumbered solution? > > Sincerely, > > Greg Daley > gdaley@au.logicalis.com > > > > > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ing-Wher Chen > Sent: Tuesday, 14 January 2014 9:53 AM > To: ipv6@ietf.org > Subject: RE: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt > > Please note that we're actively working with Ericsson's legal department on an IPR disclosure regarding the draft. > > Thanks, > Helen > > -----Original Message----- > From: Ing-Wher Chen > Sent: Monday, January 13, 2014 2:37 PM > To: 'ipv6@ietf.org' > Subject: FW: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt > > Hello, > > The informational draft below documents Ericsson's solution, deployed since early 2013, regarding Mikael's concern in the recent discussion about ND denial-of-service attacks. The draft also elaborates on Lorenzo's point regarding discovering neighbors based on DAD-NS packets. > > Thanks, > Helen > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, January 10, 2014 4:44 PM > To: Joel Halpern; Ing-Wher Chen; Joel Halpern; Ing-Wher Chen > Subject: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt > > > A new version of I-D, draft-halpern-6man-nd-pre-resolve-addr-00.txt > has been successfully submitted by I. Chen and posted to the IETF repository. > > Name: draft-halpern-6man-nd-pre-resolve-addr > Revision: 00 > Title: Triggering ND Address Resolution on Receiving DAD-NS > Document date: 2014-01-10 > Group: Individual Submission > Pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-halpern-6man-nd-pre-resolve-addr-00.txt > Status: https://datatracker.ietf.org/doc/draft-halpern-6man-nd-pre-resolve-addr/ > Htmlized: http://tools.ietf.org/html/draft-halpern-6man-nd-pre-resolve-addr-00 > > > Abstract: > This draft proposes a new optional event to trigger address > resolution using IPv6 Neighbor Discovery. This helps optimize router > performance, and can help mitigate certain potential ND-related > denial-of-service attacks. Upon receiving a DAD-NS message, the > neighbor solicitation message used to detect duplicate addresses, if > the target address encoded in the DAD-NS is not a duplicate address, > the receiving device responds by triggering address resolution for > the target address in the DAD-NS, in preparation for expectant future > communication with the sending device. > > > > > 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 nordmark@acm.org Fri Jan 17 09:22: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 15A0E1AC43F for ; Fri, 17 Jan 2014 09:22:28 -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 NUt-MsyWBHqw for ; Fri, 17 Jan 2014 09:22:27 -0800 (PST) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF371A1F19 for ; Fri, 17 Jan 2014 09:22:27 -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 s0HHM5r9031262 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 17 Jan 2014 09:22:05 -0800 Message-ID: <52D966BD.3090606@acm.org> Date: Fri, 17 Jan 2014 09:22:05 -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: Tim Chown , Ole Troan Subject: Re: MLD snooping of solicted-node multicast (Was: Re: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt References: <20140111004402.10451.90724.idtracker@ietfa.amsl.com> <72381AF1F18BAE4F890A0813768D992817FCA84E@sdcexchms.au.logicalis.com> <892FB91E-311D-4A50-A38B-4972F70847AB@employees.org> <5DC8FA82-DD79-49F5-8842-0243CDF77B7D@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;6g3j4pt/4xG5tYIY+v0w6Q== M;WMgK45t/4xG5tYIY+v0w6Q== Cc: 6man WG , Ing-Wher Chen 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, 17 Jan 2014 17:22:28 -0000 On 1/17/14 5:38 AM, Tim Chown wrote: > > On 17 Jan 2014, at 09:43, Ole Troan wrote: > >> Greg, sorry to divert your thread. >> >>> Neighbour Solicitation messages for incomplete entries (per RFC 4861 S7.2.2) will be dropped by the snooping switches if there is no Multicast subscriber for the solicited nodes' multicast address. Not only is this a mitigation of the potential attack, but also indicates an alternative for non-snooping networks: >> >> I hear that MLD snooping for the solicited-node multicast groups isn't supported in most (if not all) switches. >> partly because MLD snooping doesn't work well, but also because it becomes very costly to support state for this many multicast groups. >> >> anyone with differing experience? > > Well, MLD snooping seems very prone to bugs. We have an open case currently with a particular vendor which means if we enable MLD snooping (which is beneficial given we have several multicast IPv6 TV channels) the devices will get a little 'enthusiastic' and filter all RAs. We have had at least one similar case in the past. I guess use of MLD snooping in enterprise networks is relatively rare though. Tim, was that for WiFi APs or wireless controllers doing MLD snooping? Or good ol' Ethernet switches? The more data we have on this the better. Thanks, Erik From nordmark@acm.org Fri Jan 17 09:24: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 EE3F01A1F19 for ; Fri, 17 Jan 2014 09:24:05 -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 vn-WAuffJYjg for ; Fri, 17 Jan 2014 09:24:03 -0800 (PST) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id BDD501ACC80 for ; Fri, 17 Jan 2014 09:24:03 -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 s0HHNY6h032245 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 17 Jan 2014 09:23:34 -0800 Message-ID: <52D96716.5060605@acm.org> Date: Fri, 17 Jan 2014 09:23:34 -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: Lorenzo Colitti , =?UTF-8?B?QW5kcmV3IPCfkb0gWW91cg==?= =?UTF-8?B?dGNoZW5rbw==?= Subject: Re: Reducing the battery impact of ND References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-ID: C;8ATFF5x/4xG5rYIY+v0w6Q== M;QnDkF5x/4xG5rYIY+v0w6Q== Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 17 Jan 2014 17:24:06 -0000 On 1/10/14 8:25 PM, Lorenzo Colitti wrote: > Andrew, > > thank you for bringing solid data and analysis to the equation. That is > always appreciated. > > On Sat, Jan 11, 2014 at 8:57 AM, Andrew 👽 Yourtchenko > > wrote: > > 2) The bigger problem - the battery life: > > > This can be a real problem, yes. But as you say, I think we can mitigate > it well without changing ND at all. Lorenzo, One of your "yes please" below is a change to ND - Andrew's b) about restarting RS would require a (small) standards update. And if you work out the details on b) I suspect you'll find that to completely avoid the periodic multicast RAs the routers need to know whether hosts expect periodic RA as opposed to all the hosts doing the RS restart. That would imply some more protocol change. And just to be perfectly clear, I don't think assuming (near) perfect MLD snooping including in WiFi APs is undesirable. Hence my focus has been to remove as much as possible of the ND multicasts including the DAD and NS packets. But my overall observation is that if we think we can fix (even a subset of) this without a standards update, then we are just fooling ourselves. Regards, Erik > WiFi is a pretty expensive thing to do, power-wise. To help extend the > battery, the mobile devices try very hard to shut off the radio > whenever they can. The wireless station would go to sleep, and inform > the AP about this fact - so the AP can buffer the frames for it [1]. > Further optimizations in this area were introduced by 802.11e (WMM-PS) > [2], where the frames destined to workstation could be transmitted > more efficiently and radio duty cycle is reduced. > > Spontaneous all-hosts multicasts interfere with these mechanisms, thus > the battery drain on the devices is much higher > > > One thing that I think we haven't discussed here is that in principle, > there are *very few* all-hosts multicasts - basically, only RA. Even RS > is all-routers multicast, not all hosts. So really the only thing we're > talking about is solicited-node multicasts for NS (and occasional > unsolicited NAs, which should only really happen when nodes change their > MAC addresses. Note that I'm not talking about malicious nodes here > because any malicious node can decide to spam the link with multicast > messages regardless of what the ND protocol looks like. > > I think that using multicast instead of broadcast and defining > solicited-node multicast addresses based on the IID, were very wise > choices. This is because there are so many different groups (2^24), that > even in very large networks, each solicited-node multicast group will > likely only have one member. So - at least in principle - there are two > layers at which the battery impact of NS packets can be reduced to zero > or close to zero: > > 1. If the AP keeps state of what MAC addresses have joined which > multicast groups, it can selectively turn multicast NS into a set of > unicast NS (L2 unicast; not L3 unicast). This will be a pretty > significant bandwidth optimization both because a) as you say, > unicast is faster than multicast, and b) because one multicast NS > will almost certainly turn into only one unicast NS. Win/win. > 2. Even if the AP does not do #1, if the wifi chipset in the device > keeps state of what multicast groups the device has joined, then the > wifi chipset can simply drop packets that aren't interesting to the > device's main CPU. From experience we know that this can also lead > to massive battery savings - the wifi chipset is basically on a lot > of the time anyway, because it has to listen for beacons and > incoming packets, and this sort of filtering can be pretty efficient. > > That leaves RAs. Multicast RAs are a bane for battery life, because > every time a device joins the network, it sends an RS. If the router > responds with a multicast RA, then all devices on the link get a packet > which they didn't need. On large wifi networks, I've seen this cause RAs > once every 3-4 seconds, which is really painful in terms of battery > life. Fortunately, there's an easy solution here: respond to router > solicitations with unicast RAs sent to the sender. This is pretty > trivial, and it doesn't require any state anywhere. There is a corner > case where, if 10000 devices come online at the same time because the AP > just booted up, you can get a thundering herd problem and have to send > 10000 unicast packets, but this is can be optimized too: if the router > sees that it's sending more than 100 solicited unicast RAs per second, > it can simply send a multicast RA instead. > > - especially in a typical network where the mobile devices move, and > might trigger an RS/RA on each L2 roam between BSSIDs. > > > The client devices I'm familiar with don't send RSes when L2 roaming > between BSSIDs on the same SSID. Is this a bug? Should they? > > I hear someone saying: "Yes, but this is all about wireless, DC is all > different story - it's all switches, they don't hold the state!" - yes > and no. > > > I'd argue that it's not "yes and no", it's just "no". The state required > by the approaches I suggest above is the same amount of state as > multicast snooping, and it's pretty much the same amount of state > required by the efficient ND approach - but it doesn't require > complicating the ND protocol > > Maybe worth to split the problem area into smaller subsets and see > whether a "cheaper" solutions are possible. Let's first take the > "multicast RAs" problem, and assume we do the below steps: > > a) Allow the environments that wish to do so, to send solicited RAs > unicast. (standard already permits to do so). > > > Yes please! > > b) Have the hosts restart the Resilient RS [5] process at 1/2 or so > of router lifetime expiry: the router now can have the heuristic to > know which hosts are supporting the "unicast RA update" mechanism > *and* did not receive the periodic RA which would have been sent > usually at 1/3 the lifetime expiry (three RAs per lifetime rule of > thumb). > > > Yes please! > > c) bump up the allowable MaxRtrAdvInterval and AdvDefaultLifetime to > their maximum theoretically possible values (spec says the hosts > should already be able to handle those, I did not test though) - this > would allow to further reduce the periodic RA frequency, from 2.5 > hours today to ~18.2 hours, or, if we feel adventurous, put all-ones > to be a "solicited-only RAs by default" - thus, unless another router > sends an RA with different lifetime, refreshing the router info > becomes host-driven, with an option for a router to override at any > time. > > > This sort of depends what device you have. For example - on a mobile > phone, receiving one packet every 2.5 hours is *so far down* in the > noise that it just doesn't matter. Your phone is doing a massive amount > of stuff already - it's syncing your email, receiving wifi beacons, > checking calendar alarms, etc. etc. All of that uses way more CPU than > receiving one multicast RA. > > There may be other devices that have lower power requirements, though > I'm not sure - perhaps these devices simply can't use 802.11-style wifi > because it's too expensive, and so already have to use something like > 6LowPAN. I don't know if there's a use case here. > > These steps take care of the "multicast RA" problem. But again, also, > each of them by itself brings incremental usefulness, and is doable on > a single device => no "chicken and egg", they gradually shrink the > issue - and are compatible with the existing tweaks that solve the > same problem (in a more layer-violating way). > > > Care to work together on a document that provides operational guidance > to optimize battery impact of ND on wifi networks? Since they involve > zero protocol changes, v6ops would be a good candidate group for it. And > it might help persuade vendors that are not your employer to implement > stuff like this > > Now let's think of updating the various caches while roaming: > > > How much more do you think this sort of thing will help, assuming we do > the "100% feasible using the existing protocol" stuff above? > > NB: the above does not take care of the "defending the host's address > on behalf of the sleeping node" problem. > > > An NS is 72 bytes, and if we do multicast snooping, then a sleeping node > is only ever going to be woken up if a node with the same last 3 address > bytes shows up. That should be extremely rare. > > Cheers, > Lorenzo > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From Dmitry.Anipko@microsoft.com Fri Jan 17 10:39: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 7A03E1AD73F for ; Fri, 17 Jan 2014 10:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 8lB9XCXzAJys for ; Fri, 17 Jan 2014 10:39:29 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id 035B11ACC87 for ; Fri, 17 Jan 2014 10:39:28 -0800 (PST) Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB079.namprd03.prod.outlook.com (10.255.175.155) with Microsoft SMTP Server (TLS) id 15.0.847.13; Fri, 17 Jan 2014 18:39:15 +0000 Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.253]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.253]) with mapi id 15.00.0847.008; Fri, 17 Jan 2014 18:39:15 +0000 From: Dmitry Anipko To: Lorenzo Colitti , Ole Troan Subject: RE: MLD snooping of solicted-node multicast (Was: Re: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt Thread-Topic: MLD snooping of solicted-node multicast (Was: Re: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt Thread-Index: AQHPDmY2hGYF66RRbk+N6Vv6p523J5qDMmwwgAATMeCABOYbYIAAiLsAgAABWYCAAJJtcA== Date: Fri, 17 Jan 2014 18:39:15 +0000 Message-ID: <2c30d818adc447b2a0ca3a7f0556ee65@SN2PR03MB077.namprd03.prod.outlook.com> References: <20140111004402.10451.90724.idtracker@ietfa.amsl.com> <72381AF1F18BAE4F890A0813768D992817FCA84E@sdcexchms.au.logicalis.com> <892FB91E-311D-4A50-A38B-4972F70847AB@employees.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::2] x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(689001)(679001)(779001)(377454003)(189002)(199002)(24454002)(74366001)(74662001)(53806001)(54356001)(76482001)(77096001)(2656002)(81686001)(81342001)(80976001)(87936001)(87266001)(56816005)(85852003)(65816001)(81816001)(51856001)(74502001)(31966008)(33646001)(74706001)(90146001)(76796001)(76786001)(47446002)(83072002)(76576001)(50986001)(74316001)(19300405004)(15202345003)(79102001)(74876001)(19580405001)(69226001)(47736001)(46102001)(54316002)(59766001)(15975445006)(85306002)(81542001)(77982001)(49866001)(19580395003)(19609705001)(80022001)(92566001)(63696002)(4396001)(56776001)(93136001)(47976001)(16236675002)(83322001)(93516002)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB079; H:SN2PR03MB077.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ee43::2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_2c30d818adc447b2a0ca3a7f0556ee65SN2PR03MB077namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: 6man WG , Ing-Wher Chen 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, 17 Jan 2014 18:39:30 -0000 --_000_2c30d818adc447b2a0ca3a7f0556ee65SN2PR03MB077namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pj4gVGhlcmUgYXJlIGJhc2ljYWxseSB0d28gc29saWNpdGVkLW5vZGUgZ3JvdXBzIHBlciBob3N0 DQoNCkRvZXMgdGhpcyBhc3N1bWUgdGhhdCB0eXBpY2FsbHkgdGhlcmUgYXJlIG9ubHkgMiBub24g bGluay1sb2NhbCBJUHY2IGFkZHJlc3NlcyAgcGVyIGhvc3Q/IChzaW5jZSBkaWZmZXJlbnQgYWRk cmVzc2VzIGFyZSB1bmxpa2VseSB0byBmYWxsIGluIHRoZSBzYW1lIGdyb3VwLCBhcyBsb25nIGFz IHRoZXkgaGF2ZSBkaWZmZXJlbnQgaW50ZXJmYWNlIGlkZW50aWZpZXJzKQ0KDQpGcm9tOiBpcHY2 IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTG9yZW56byBDb2xp dHRpDQpTZW50OiBGcmlkYXksIEphbnVhcnkgMTcsIDIwMTQgMTo0OSBBTQ0KVG86IE9sZSBUcm9h bg0KQ2M6IEluZy1XaGVyIENoZW47IDZtYW4gV0cNClN1YmplY3Q6IFJlOiBNTEQgc25vb3Bpbmcg b2Ygc29saWN0ZWQtbm9kZSBtdWx0aWNhc3QgKFdhczogUmU6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtaGFscGVybi02bWFuLW5kLXByZS1yZXNvbHZlLWFkZHItMDAudHh0DQoN Ck9uIEZyaSwgSmFuIDE3LCAyMDE0IGF0IDE6NDMgQU0sIE9sZSBUcm9hbiA8b3Ryb2FuQGVtcGxv eWVlcy5vcmc8bWFpbHRvOm90cm9hbkBlbXBsb3llZXMub3JnPj4gd3JvdGU6DQpJIGhlYXIgdGhh dCBNTEQgc25vb3BpbmcgZm9yIHRoZSBzb2xpY2l0ZWQtbm9kZSBtdWx0aWNhc3QgZ3JvdXBzIGlz bid0IHN1cHBvcnRlZCBpbiBtb3N0IChpZiBub3QgYWxsKSBzd2l0Y2hlcy4NCnBhcnRseSBiZWNh dXNlIE1MRCBzbm9vcGluZyBkb2Vzbid0IHdvcmsgd2VsbCwgYnV0IGFsc28gYmVjYXVzZSBpdCBi ZWNvbWVzIHZlcnkgY29zdGx5IHRvIHN1cHBvcnQgc3RhdGUgZm9yIHRoaXMgbWFueSBtdWx0aWNh c3QgZ3JvdXBzLg0KDQpPbiB3aWZpIG5ldHdvcmtzLCBJIGRvbid0IHNlZSB3aHkgdGhhdCB3b3Vs ZCBiZS4gVGhlcmUgYXJlIGJhc2ljYWxseSB0d28gc29saWNpdGVkLW5vZGUgZ3JvdXBzIHBlciBo b3N0LCBhbmQgd2lmaSBhY2Nlc3MgcG9pbnRzIGFscmVhZHkgdHJhY2sgbG90cyBvZiBzdGF0ZSBv biBhIHBlci1NQUMgYWRkcmVzcyBiYXNpcy4NCg== --_000_2c30d818adc447b2a0ca3a7f0556ee65SN2PR03MB077namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDsmZ3Q7 PC9zcGFuPiBUaGVyZSBhcmUgYmFzaWNhbGx5IHR3byBzb2xpY2l0ZWQtbm9kZSBncm91cHMgcGVy IGhvc3Q8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5Eb2VzIHRoaXMgYXNzdW1lIHRoYXQgdHlwaWNhbGx5IHRoZXJlIGFyZSBvbmx5IDIgbm9uIGxp bmstbG9jYWwgSVB2NiBhZGRyZXNzZXMgJm5ic3A7cGVyIGhvc3Q/IChzaW5jZSBkaWZmZXJlbnQg YWRkcmVzc2VzIGFyZSB1bmxpa2VseSB0byBmYWxsIGluIHRoZSBzYW1lIGdyb3VwLA0KIGFzIGxv bmcgYXMgdGhleSBoYXZlIGRpZmZlcmVudCBpbnRlcmZhY2UgaWRlbnRpZmllcnMpPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21w b3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IGlwdjYgW21haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPkxvcmVuem8gQ29saXR0aTxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEphbnVh cnkgMTcsIDIwMTQgMTo0OSBBTTxicj4NCjxiPlRvOjwvYj4gT2xlIFRyb2FuPGJyPg0KPGI+Q2M6 PC9iPiBJbmctV2hlciBDaGVuOyA2bWFuIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBNTEQg c25vb3Bpbmcgb2Ygc29saWN0ZWQtbm9kZSBtdWx0aWNhc3QgKFdhczogUmU6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaGFscGVybi02bWFuLW5kLXByZS1yZXNvbHZlLWFkZHIt MDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBGcmksIEphbiAxNywgMjAxNCBhdCAxOjQzIEFNLCBPbGUgVHJvYW4gJmx0OzxhIGhyZWY9 Im1haWx0bzpvdHJvYW5AZW1wbG95ZWVzLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm90cm9hbkBlbXBs b3llZXMub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBoZWFyIHRoYXQgTUxEIHNub29waW5nIGZvciB0aGUgc29saWNp dGVkLW5vZGUgbXVsdGljYXN0IGdyb3VwcyBpc24ndCBzdXBwb3J0ZWQgaW4gbW9zdCAoaWYgbm90 IGFsbCkgc3dpdGNoZXMuPGJyPg0KcGFydGx5IGJlY2F1c2UgTUxEIHNub29waW5nIGRvZXNuJ3Qg d29yayB3ZWxsLCBidXQgYWxzbyBiZWNhdXNlIGl0IGJlY29tZXMgdmVyeSBjb3N0bHkgdG8gc3Vw cG9ydCBzdGF0ZSBmb3IgdGhpcyBtYW55IG11bHRpY2FzdCBncm91cHMuPG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiB3aWZpIG5l dHdvcmtzLCBJIGRvbid0IHNlZSB3aHkgdGhhdCB3b3VsZCBiZS4gVGhlcmUgYXJlIGJhc2ljYWxs eSB0d28gc29saWNpdGVkLW5vZGUgZ3JvdXBzIHBlciBob3N0LCBhbmQgd2lmaSBhY2Nlc3MgcG9p bnRzIGFscmVhZHkgdHJhY2sgbG90cyBvZiBzdGF0ZSBvbiBhIHBlci1NQUMgYWRkcmVzcyBiYXNp cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2c30d818adc447b2a0ca3a7f0556ee65SN2PR03MB077namprd03pro_-- From lorenzo@google.com Fri Jan 17 11:02: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 9AC631AE169 for ; Fri, 17 Jan 2014 11:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, 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 Uc94hJCxjhsw for ; Fri, 17 Jan 2014 11:02:16 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id DE4A31AD939 for ; Fri, 17 Jan 2014 11:02:14 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id as1so6036917iec.13 for ; Fri, 17 Jan 2014 11:02:02 -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=uzLMQ4sgLzN0JyHMXWyDz8KRaUtSijKCeQeBhQtXXh0=; b=bQtw5bZSWhJpEyLDXc+6az/jUpC1qA9ghLF+5scBG17SkxnFmQsiwFjclZOrth0ICr +zxnJXrrHO/fsmzFzOB+lITaQkIf572IOpHaZ+/GPK+iXkSoGGm69Dw1+pBSG9/Tr6Ff K0ZyfT7Q+soc6SpxS3suTHgNkX9BZDVFaq+u1kM5vs7R1/sP2Q+r+PCYqETNZUZikozW b+gr0jThqPxGaesOvB9z0fJTstdJsF3jX4L3zExQiqdSuSPywm6UrluDQZhuG3s9gphb RZYcpCXnu2rLuMkpRPIayW6wMy7vEjCsJDU+Jyo2LKtIyvAwPu69AvwNuDHskqqTnEQu /m6A== 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=uzLMQ4sgLzN0JyHMXWyDz8KRaUtSijKCeQeBhQtXXh0=; b=kFEx6lWOGuzsLpPDDDdtjMWezaI49wmuOkgP6K3AW+0me0jAnNi4ve6idvWZvTGdBL DHXyAdzXxvQpUVNTV4w36Zgkv148D643NlSm6+a/wE1v66ro2rz874ZI7YtKbxFfSBX9 5Qg3CkQQhvYkben3p03qfBAi+OtITxFmir6g6YbTyoVTPtYg0oRkXyYjoqoPvTwKA3Nz zvYhyDXIe4EHJuOiyFFSPnVd/4IrnG5TT3h4IXpo7e+Iey9houmeDkV+1ZC1lnd+abHm +8t5xJQ9UanXUvn2okdFt7gfTCrkNT/mK5UIypeb+s04KZfc1SWsS1uuhIFPuyG12Axq zKtQ== X-Gm-Message-State: ALoCoQlRZ1Mlus8r5HEVuq8sD6/QFn3dHmEOlDqurAePgzX2S9wbaa2Fm+XsgF1LqgIVmbrTUf0/I20RHqljERWpr2n7oWhkCUDqiskfAVJd5/Mte/gwrMWpcgYx/t6Lqywu3Se/GhXnARPKa2XosqaywLhsZ+oK3SnLad16uc/m4uA3AtAdGy42UcoO0DXhIC/Wz8Lru0VH X-Received: by 10.43.103.67 with SMTP id dh3mr3261891icc.60.1389985322282; Fri, 17 Jan 2014 11:02:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Fri, 17 Jan 2014 11:01:42 -0800 (PST) In-Reply-To: <2c30d818adc447b2a0ca3a7f0556ee65@SN2PR03MB077.namprd03.prod.outlook.com> References: <20140111004402.10451.90724.idtracker@ietfa.amsl.com> <72381AF1F18BAE4F890A0813768D992817FCA84E@sdcexchms.au.logicalis.com> <892FB91E-311D-4A50-A38B-4972F70847AB@employees.org> <2c30d818adc447b2a0ca3a7f0556ee65@SN2PR03MB077.namprd03.prod.outlook.com> From: Lorenzo Colitti Date: Fri, 17 Jan 2014 11:01:42 -0800 Message-ID: Subject: Re: MLD snooping of solicted-node multicast (Was: Re: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt To: Dmitry Anipko Content-Type: multipart/alternative; boundary=bcaec517201f60d65d04f02f2d6a Cc: 6man WG , Ing-Wher Chen 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, 17 Jan 2014 19:02:17 -0000 --bcaec517201f60d65d04f02f2d6a Content-Type: text/plain; charset=UTF-8 On Fri, Jan 17, 2014 at 10:39 AM, Dmitry Anipko wrote: > >> There are basically two solicited-node groups per host > > > > Does this assume that typically there are only 2 non link-local IPv6 > addresses per host? (since different addresses are unlikely to fall in the > same group, as long as they have different interface identifiers) > A more precise statement would be that the number of solicited-node groups scales linearly with the number of IPv6 addresses assigned to hosts, which is something that people don't usually seem to worry about. --bcaec517201f60d65d04f02f2d6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 17, 2014 at 10:39 AM, Dmitry Anipko <Dmitry.Anipko@mic= rosoft.com> wrote:

>> There are= basically two solicited-node groups per host=

=C2=A0

Does this assume th= at typically there are only 2 non link-local IPv6 addresses =C2=A0per host?= (since different addresses are unlikely to fall in the same group, as long as they have different interface identifiers)


A more precise statement would be that t= he number of solicited-node groups scales linearly with the number of IPv6 = addresses assigned to hosts, which is something that people don't usual= ly seem to worry about.
--bcaec517201f60d65d04f02f2d6a-- From nordmark@sonic.net Fri Jan 17 09:21: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 82F5F1AE174 for ; Fri, 17 Jan 2014 09:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538] 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 xsTibb7HIiKf for ; Fri, 17 Jan 2014 09:20:58 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE771AE175 for ; Fri, 17 Jan 2014 09:20:58 -0800 (PST) Received: from [10.0.1.44] (184-23-158-201.dsl.dynamic.sonic.net [184.23.158.201]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s0HHKZvS030008 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 17 Jan 2014 09:20:36 -0800 Message-ID: <52D96663.6060005@sonic.net> Date: Fri, 17 Jan 2014 09:20:35 -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: Lorenzo Colitti , =?UTF-8?B?QW5kcmV3IPCfkb0gWW91cg==?= =?UTF-8?B?dGNoZW5rbw==?= Subject: Re: Reducing the battery impact of ND References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-ID: C;GiuKrZt/4xGB1jqjisUCUQ== M;0PnDrZt/4xGB1jqjisUCUQ== X-Mailman-Approved-At: Fri, 17 Jan 2014 11:10:39 -0800 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 17 Jan 2014 17:21:00 -0000 On 1/10/14 8:25 PM, Lorenzo Colitti wrote: > Andrew, > > thank you for bringing solid data and analysis to the equation. That is > always appreciated. > > On Sat, Jan 11, 2014 at 8:57 AM, Andrew 👽 Yourtchenko > > wrote: > > 2) The bigger problem - the battery life: > > > This can be a real problem, yes. But as you say, I think we can mitigate > it well without changing ND at all. Lorenzo, One of your "yes please" below is a change to ND - Andrew's b) about restarting RS would require a (small) standards update. And if you work out the details on b) I suspect you'll find that to completely avoid the periodic multicast RAs the routers need to know whether hosts expect periodic RA as opposed to all the hosts doing the RS restart. That would imply some more protocol change. And just to be perfectly clear, I don't think assuming (near) perfect MLD snooping including in WiFi APs is undesirable. Hence my focus has been to remove as much as possible of the ND multicasts including the DAD and NS packets. But my overall observation is that if we think we can fix (even a subset of) this without a standards update, then we are just fooling ourselves. Regards, Erik > WiFi is a pretty expensive thing to do, power-wise. To help extend the > battery, the mobile devices try very hard to shut off the radio > whenever they can. The wireless station would go to sleep, and inform > the AP about this fact - so the AP can buffer the frames for it [1]. > Further optimizations in this area were introduced by 802.11e (WMM-PS) > [2], where the frames destined to workstation could be transmitted > more efficiently and radio duty cycle is reduced. > > Spontaneous all-hosts multicasts interfere with these mechanisms, thus > the battery drain on the devices is much higher > > > One thing that I think we haven't discussed here is that in principle, > there are *very few* all-hosts multicasts - basically, only RA. Even RS > is all-routers multicast, not all hosts. So really the only thing we're > talking about is solicited-node multicasts for NS (and occasional > unsolicited NAs, which should only really happen when nodes change their > MAC addresses. Note that I'm not talking about malicious nodes here > because any malicious node can decide to spam the link with multicast > messages regardless of what the ND protocol looks like. > > I think that using multicast instead of broadcast and defining > solicited-node multicast addresses based on the IID, were very wise > choices. This is because there are so many different groups (2^24), that > even in very large networks, each solicited-node multicast group will > likely only have one member. So - at least in principle - there are two > layers at which the battery impact of NS packets can be reduced to zero > or close to zero: > > 1. If the AP keeps state of what MAC addresses have joined which > multicast groups, it can selectively turn multicast NS into a set of > unicast NS (L2 unicast; not L3 unicast). This will be a pretty > significant bandwidth optimization both because a) as you say, > unicast is faster than multicast, and b) because one multicast NS > will almost certainly turn into only one unicast NS. Win/win. > 2. Even if the AP does not do #1, if the wifi chipset in the device > keeps state of what multicast groups the device has joined, then the > wifi chipset can simply drop packets that aren't interesting to the > device's main CPU. From experience we know that this can also lead > to massive battery savings - the wifi chipset is basically on a lot > of the time anyway, because it has to listen for beacons and > incoming packets, and this sort of filtering can be pretty efficient. > > That leaves RAs. Multicast RAs are a bane for battery life, because > every time a device joins the network, it sends an RS. If the router > responds with a multicast RA, then all devices on the link get a packet > which they didn't need. On large wifi networks, I've seen this cause RAs > once every 3-4 seconds, which is really painful in terms of battery > life. Fortunately, there's an easy solution here: respond to router > solicitations with unicast RAs sent to the sender. This is pretty > trivial, and it doesn't require any state anywhere. There is a corner > case where, if 10000 devices come online at the same time because the AP > just booted up, you can get a thundering herd problem and have to send > 10000 unicast packets, but this is can be optimized too: if the router > sees that it's sending more than 100 solicited unicast RAs per second, > it can simply send a multicast RA instead. > > - especially in a typical network where the mobile devices move, and > might trigger an RS/RA on each L2 roam between BSSIDs. > > > The client devices I'm familiar with don't send RSes when L2 roaming > between BSSIDs on the same SSID. Is this a bug? Should they? > > I hear someone saying: "Yes, but this is all about wireless, DC is all > different story - it's all switches, they don't hold the state!" - yes > and no. > > > I'd argue that it's not "yes and no", it's just "no". The state required > by the approaches I suggest above is the same amount of state as > multicast snooping, and it's pretty much the same amount of state > required by the efficient ND approach - but it doesn't require > complicating the ND protocol > > Maybe worth to split the problem area into smaller subsets and see > whether a "cheaper" solutions are possible. Let's first take the > "multicast RAs" problem, and assume we do the below steps: > > a) Allow the environments that wish to do so, to send solicited RAs > unicast. (standard already permits to do so). > > > Yes please! > > b) Have the hosts restart the Resilient RS [5] process at 1/2 or so > of router lifetime expiry: the router now can have the heuristic to > know which hosts are supporting the "unicast RA update" mechanism > *and* did not receive the periodic RA which would have been sent > usually at 1/3 the lifetime expiry (three RAs per lifetime rule of > thumb). > > > Yes please! > > c) bump up the allowable MaxRtrAdvInterval and AdvDefaultLifetime to > their maximum theoretically possible values (spec says the hosts > should already be able to handle those, I did not test though) - this > would allow to further reduce the periodic RA frequency, from 2.5 > hours today to ~18.2 hours, or, if we feel adventurous, put all-ones > to be a "solicited-only RAs by default" - thus, unless another router > sends an RA with different lifetime, refreshing the router info > becomes host-driven, with an option for a router to override at any > time. > > > This sort of depends what device you have. For example - on a mobile > phone, receiving one packet every 2.5 hours is *so far down* in the > noise that it just doesn't matter. Your phone is doing a massive amount > of stuff already - it's syncing your email, receiving wifi beacons, > checking calendar alarms, etc. etc. All of that uses way more CPU than > receiving one multicast RA. > > There may be other devices that have lower power requirements, though > I'm not sure - perhaps these devices simply can't use 802.11-style wifi > because it's too expensive, and so already have to use something like > 6LowPAN. I don't know if there's a use case here. > > These steps take care of the "multicast RA" problem. But again, also, > each of them by itself brings incremental usefulness, and is doable on > a single device => no "chicken and egg", they gradually shrink the > issue - and are compatible with the existing tweaks that solve the > same problem (in a more layer-violating way). > > > Care to work together on a document that provides operational guidance > to optimize battery impact of ND on wifi networks? Since they involve > zero protocol changes, v6ops would be a good candidate group for it. And > it might help persuade vendors that are not your employer to implement > stuff like this :-) > > Now let's think of updating the various caches while roaming: > > > How much more do you think this sort of thing will help, assuming we do > the "100% feasible using the existing protocol" stuff above? > > NB: the above does not take care of the "defending the host's address > on behalf of the sleeping node" problem. > > > An NS is 72 bytes, and if we do multicast snooping, then a sleeping node > is only ever going to be woken up if a node with the same last 3 address > bytes shows up. That should be extremely rare. > > Cheers, > Lorenzo > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From Dmitry.Anipko@microsoft.com Fri Jan 17 11:14:52 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 0F2571AE11D for ; Fri, 17 Jan 2014 11:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 j5uQtGB9ebWG for ; Fri, 17 Jan 2014 11:14:49 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 92B131ADF78 for ; Fri, 17 Jan 2014 11:14:49 -0800 (PST) Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB079.namprd03.prod.outlook.com (10.255.175.155) with Microsoft SMTP Server (TLS) id 15.0.847.13; Fri, 17 Jan 2014 19:14:35 +0000 Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.253]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.253]) with mapi id 15.00.0847.008; Fri, 17 Jan 2014 19:14:35 +0000 From: Dmitry Anipko To: Lorenzo Colitti Subject: RE: MLD snooping of solicted-node multicast (Was: Re: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt Thread-Topic: MLD snooping of solicted-node multicast (Was: Re: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt Thread-Index: AQHPDmY2hGYF66RRbk+N6Vv6p523J5qDMmwwgAATMeCABOYbYIAAiLsAgAABWYCAAJJtcIAACBgAgAACmS4= Date: Fri, 17 Jan 2014 19:14:35 +0000 Message-ID: <5e8d384f3009492fbe3992d82176aa26@SN2PR03MB077.namprd03.prod.outlook.com> References: <20140111004402.10451.90724.idtracker@ietfa.amsl.com> <72381AF1F18BAE4F890A0813768D992817FCA84E@sdcexchms.au.logicalis.com> <892FB91E-311D-4A50-A38B-4972F70847AB@employees.org> <2c30d818adc447b2a0ca3a7f0556ee65@SN2PR03MB077.namprd03.prod.outlook.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::2] x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(689001)(679001)(779001)(377454003)(51694002)(189002)(199002)(24454002)(74366001)(74662001)(53806001)(54356001)(76482001)(77096001)(2656002)(81686001)(81342001)(80976001)(87936001)(87266001)(56816005)(85852003)(65816001)(81816001)(51856001)(74502001)(31966008)(33646001)(74706001)(90146001)(76796001)(76786001)(47446002)(83072002)(76576001)(50986001)(74316001)(79102001)(74876001)(19580405001)(69226001)(47736001)(46102001)(54316002)(59766001)(85306002)(81542001)(77982001)(49866001)(19580395003)(80022001)(92566001)(63696002)(4396001)(56776001)(93136001)(47976001)(16236675002)(83322001)(93516002)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB079; H:SN2PR03MB077.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ee43::2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_5e8d384f3009492fbe3992d82176aa26SN2PR03MB077namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: 6man WG , Ing-Wher Chen 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, 17 Jan 2014 19:14:52 -0000 --_000_5e8d384f3009492fbe3992d82176aa26SN2PR03MB077namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >>A more precise statement would be that the number of solicited-node group= s scales linearly with the number of IPv6 addresses assigned to hosts, Agreed. And generally, number of addresses can be more than 2-3 (because of= multiple prefixes, and because of multiple suffixes due to privacy extensi= ons). >>which is something that people don't usually seem to worry about. We have recently seen issues in some APs, where they were not able to handl= e multiple addresses per host, because of some state maintained per host (t= hat's not a justification that host should not have multiple addresses, but= I just wanted to note that today there are issues in some cases related to= that). ________________________________ From: Lorenzo Colitti Sent: Friday, January 17, 2014 11:01 AM To: Dmitry Anipko Cc: Ole Troan; Ing-Wher Chen; 6man WG Subject: Re: MLD snooping of solicted-node multicast (Was: Re: New Version = Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt On Fri, Jan 17, 2014 at 10:39 AM, Dmitry Anipko > wrote: >> There are basically two solicited-node groups per host Does this assume that typically there are only 2 non link-local IPv6 addres= ses per host? (since different addresses are unlikely to fall in the same = group, as long as they have different interface identifiers) A more precise statement would be that the number of solicited-node groups = scales linearly with the number of IPv6 addresses assigned to hosts, which = is something that people don't usually seem to worry about. --_000_5e8d384f3009492fbe3992d82176aa26SN2PR03MB077namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>>A more = precise statement would be that the number of solicited-node groups scales = linearly with the number of IPv6 addresses assigned to hosts, <= /p>


Agreed. And gen= erally, number of addresses can be more than 2-3 (because of multiple prefi= xes, and because of multiple suffixes due to privacy extensions).


>>which i= s something that people don't usually seem to worry about.


We have recentl= y seen issues in some APs, where they were not able to handle multiple addr= esses per host, because of some state maintained per host (that's not a jus= tification that host should not have multiple addresses, but I just wanted to note that today there are issues = in some cases related to that).


From: Lorenzo Colitti <l= orenzo@google.com>
Sent: Friday, January 17, 2014 11:01 AM
To: Dmitry Anipko
Cc: Ole Troan; Ing-Wher Chen; 6man WG
Subject: Re: MLD snooping of solicted-node multicast (Was: Re: New V= ersion Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt
 
On Fri, Jan 17, 2014 at 10:39 AM, Dmitry Anipko = <Dmitry= .Anipko@microsoft.com> wrote:

>> There a= re basically two solicited-node groups per host

 

Does this assume that t= ypically there are only 2 non link-local IPv6 addresses  per host? (si= nce different addresses are unlikely to fall in the same group, as long as they have different interface identifiers)


A more precise statement would be that the number of solicited-node gr= oups scales linearly with the number of IPv6 addresses assigned to hosts, w= hich is something that people don't usually seem to worry about.
--_000_5e8d384f3009492fbe3992d82176aa26SN2PR03MB077namprd03pro_-- From lorenzo@google.com Fri Jan 17 11:37: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 BAA771AC82A for ; Fri, 17 Jan 2014 11:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, 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 KY0_V4dCSBEB for ; Fri, 17 Jan 2014 11:37:17 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 182FE1A1F63 for ; Fri, 17 Jan 2014 11:37:17 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id tq11so4080084ieb.14 for ; Fri, 17 Jan 2014 11:37:04 -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=tnhWBDVUGiwmhI4twLTcPr8QgMMRnSZ0IGZWD1AGJkk=; b=QNknVSs6/gtWNYEBSeynGBnP8I9u2iLpd4TdGVaD7+xHMqqDcvmovVfAU/ZZ4IAXcu dSKpQi9W+7wuqWIUK/Y6MYJce3K9MKEk7HF4AcIaUlVpbs0zfB97ODtNK+m379mZpweL k3UM6jEsHOkqCZcWAYOhAGAkevCg6eGbtapV5IHCUZxCXPfdpdt/jIBoH5D7IjVdcSng TSgCPq3QMJJ0iKCd/RMtzX+VMN3AGhfzvYmGvVVjAQ4xeAlrDK4GREFDqxpRDphe5GXU nE+9RiWJMucy0YXXmbWrBjzxDTQWK2+JOti4tSiPLFDRUriIgSzSmA9jyV0iZZyeSpbY BmOQ== 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=tnhWBDVUGiwmhI4twLTcPr8QgMMRnSZ0IGZWD1AGJkk=; b=L0GuT0xBmQqyHPRjO1DIx79NRwsLwP+aDM7nvyB28TUxy4SVYkhcwRgEpV3tvHFa3Y lsuIbkLGbdKDgKfczEunQ+6B/+yTsmfX313o7/qdelaQWkyWnpuBihRq6uoi94eiw14l flWbgI59DHvvQEk8gqM2WOM0OyMs7hBYvXkHal4QjsobMIHvZN/CzPNP9GpH16JedzU2 DtNjl2SKyuOA4TLPNo4pqGnWoWdMkopw+nGdBqjyA7XrdiushhrcHgtUI1ZVRJeudHMy ha9LvNx/kcHwAPBz3cSRL5yd3UiMruFI3j2oDqeZsaMJtbgS6O0uqzG6gS2GZzRCY+V/ CCqQ== X-Gm-Message-State: ALoCoQlEgqgp0RoaoBkWvd2vadPAMDRzpTWSFp0h8Omv1XXdpub0DZACzxn91T2VLzv8yxt9DofKkYVCOuKBpzEdvTmdvWn3xf/GMvbS5zL7Dtp6eK44zzKG1T+Y0nibfnfda97P4kvt3kIIx/MAPDzCl9K0SgwetIMEwPyTchYePZiMNIJYIKBi+8Xjl1WkAEuyzxxAH/00 X-Received: by 10.50.79.228 with SMTP id m4mr4789709igx.47.1389987424383; Fri, 17 Jan 2014 11:37:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Fri, 17 Jan 2014 11:36:44 -0800 (PST) In-Reply-To: <5e8d384f3009492fbe3992d82176aa26@SN2PR03MB077.namprd03.prod.outlook.com> References: <20140111004402.10451.90724.idtracker@ietfa.amsl.com> <72381AF1F18BAE4F890A0813768D992817FCA84E@sdcexchms.au.logicalis.com> <892FB91E-311D-4A50-A38B-4972F70847AB@employees.org> <2c30d818adc447b2a0ca3a7f0556ee65@SN2PR03MB077.namprd03.prod.outlook.com> <5e8d384f3009492fbe3992d82176aa26@SN2PR03MB077.namprd03.prod.outlook.com> From: Lorenzo Colitti Date: Fri, 17 Jan 2014 11:36:44 -0800 Message-ID: Subject: Re: MLD snooping of solicted-node multicast (Was: Re: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt To: Dmitry Anipko Content-Type: multipart/alternative; boundary=089e013a1f16ac58c704f02faad7 Cc: 6man WG , Ing-Wher Chen 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, 17 Jan 2014 19:37:18 -0000 --089e013a1f16ac58c704f02faad7 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 17, 2014 at 11:14 AM, Dmitry Anipko wrote: > >>A more precise statement would be that the number of solicited-node > groups scales linearly with the number of IPv6 addresses assigned to hosts, > > Agreed. And generally, number of addresses can be more than 2-3 (because > of multiple prefixes, and because of multiple suffixes due to privacy > extensions). > Indeed. But in the common case of a wifi network where devices come and go frequently, you'll typically have only a link-local, a global, and one temporary address. If you use EUI-64 the link-local and the global will be on the same group. > We have recently seen issues in some APs, where they were not able to > handle multiple addresses per host, because of some state maintained per > host (that's not a justification that host should not have multiple > addresses, but I just wanted to note that today there are issues in some > cases related to that). > We should clarify that such behaviour is broken and that saying, "it works in IPv4, so we should just use DHCPv6 for address assignment so that we can force the host to have only one address" is not a solution. --089e013a1f16ac58c704f02faad7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 17, 2014 at 11:14 AM, Dmitry Anipko <Dmitry.Anipko@mic= rosoft.com> wrote:

>>A more precis= e statement would be that the number of solicited-node groups scales linear= ly with the number of IPv6 addresses assigned to hosts,=C2=A0

Agreed. And gen= erally, number of addresses can be more than 2-3 (because of multiple prefi= xes, and because of multiple suffixes due to privacy extensions).

Indeed. But in the common case of a wifi netw= ork where devices come and go frequently, you'll typically have only a = link-local, a global, and one temporary address. If you use EUI-64 the link= -local and the global will be on the same group.
=C2=A0

We have recently seen= issues in some APs, where they were not able to handle multiple addresses = per host, because of some state maintained per host (that's not a justi= fication that host should not have multiple addresses, but I just wanted to note that today there are issues = in some cases related to that).

We should clarify that such behaviour is broken and that saying, &qu= ot;it works in IPv4, so we should just use DHCPv6 for address assignment so= that we can force the host to have only one address" is not a solutio= n.
--089e013a1f16ac58c704f02faad7-- From Dmitry.Anipko@microsoft.com Fri Jan 17 11:41: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 2F4451AE168 for ; Fri, 17 Jan 2014 11:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 oMfpZKgxZzXX for ; Fri, 17 Jan 2014 11:41:11 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 930741AE0F3 for ; Fri, 17 Jan 2014 11:41:11 -0800 (PST) Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB080.namprd03.prod.outlook.com (10.255.175.156) with Microsoft SMTP Server (TLS) id 15.0.847.13; Fri, 17 Jan 2014 19:40:57 +0000 Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.253]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.253]) with mapi id 15.00.0847.008; Fri, 17 Jan 2014 19:40:57 +0000 From: Dmitry Anipko To: Lorenzo Colitti Subject: RE: MLD snooping of solicted-node multicast (Was: Re: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt Thread-Topic: MLD snooping of solicted-node multicast (Was: Re: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt Thread-Index: AQHPDmY2hGYF66RRbk+N6Vv6p523J5qDMmwwgAATMeCABOYbYIAAiLsAgAABWYCAAJJtcIAACBgAgAACmS6AAAcxAIAAAL0g Date: Fri, 17 Jan 2014 19:40:56 +0000 Message-ID: <35d4e6f484974024bfe4e00b4e51ca8f@SN2PR03MB077.namprd03.prod.outlook.com> References: <20140111004402.10451.90724.idtracker@ietfa.amsl.com> <72381AF1F18BAE4F890A0813768D992817FCA84E@sdcexchms.au.logicalis.com> <892FB91E-311D-4A50-A38B-4972F70847AB@employees.org> <2c30d818adc447b2a0ca3a7f0556ee65@SN2PR03MB077.namprd03.prod.outlook.com> <5e8d384f3009492fbe3992d82176aa26@SN2PR03MB077.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::2] x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(689001)(679001)(779001)(199002)(377454003)(189002)(51694002)(24454002)(2656002)(16236675002)(50986001)(47976001)(87266001)(56776001)(77982001)(81542001)(54316002)(85306002)(19580395003)(83322001)(49866001)(19580405001)(87936001)(47736001)(4396001)(19609705001)(31966008)(54356001)(19300405004)(80976001)(53806001)(79102001)(74706001)(76576001)(77096001)(74316001)(81686001)(65816001)(81816001)(81342001)(46102001)(59766001)(47446002)(74502001)(51856001)(74662001)(56816005)(33646001)(74366001)(15975445006)(92566001)(85852003)(90146001)(80022001)(76482001)(69226001)(74876001)(15202345003)(63696002)(93136001)(76786001)(76796001)(93516002)(83072002)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB080; H:SN2PR03MB077.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ee43::2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_35d4e6f484974024bfe4e00b4e51ca8fSN2PR03MB077namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: 6man WG , Ing-Wher Chen 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, 17 Jan 2014 19:41:14 -0000 --_000_35d4e6f484974024bfe4e00b4e51ca8fSN2PR03MB077namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pj4gV2Ugc2hvdWxkIGNsYXJpZnkgdGhhdCBzdWNoIGJlaGF2aW91ciBpcyBicm9rZW4gYW5kIHRo YXQgc2F5aW5nLCAiaXQgd29ya3MgaW4gSVB2NCwgc28gd2Ugc2hvdWxkIGp1c3QgdXNlIERIQ1B2 NiBmb3IgYWRkcmVzcyBhc3NpZ25tZW50IHNvIHRoYXQgd2UgY2FuIGZvcmNlIHRoZSBob3N0IHRv IGhhdmUgb25seSBvbmUgYWRkcmVzcyIgaXMgbm90IGEgc29sdXRpb24uDQoNCkFncmVlIHdpdGgg eW91Lg0KDQpGcm9tOiBMb3JlbnpvIENvbGl0dGkgW21haWx0bzpsb3JlbnpvQGdvb2dsZS5jb21d DQpTZW50OiBGcmlkYXksIEphbnVhcnkgMTcsIDIwMTQgMTE6MzcgQU0NClRvOiBEbWl0cnkgQW5p cGtvDQpDYzogT2xlIFRyb2FuOyBJbmctV2hlciBDaGVuOyA2bWFuIFdHDQpTdWJqZWN0OiBSZTog TUxEIHNub29waW5nIG9mIHNvbGljdGVkLW5vZGUgbXVsdGljYXN0IChXYXM6IFJlOiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhhbHBlcm4tNm1hbi1uZC1wcmUtcmVzb2x2ZS1h ZGRyLTAwLnR4dA0KDQpPbiBGcmksIEphbiAxNywgMjAxNCBhdCAxMToxNCBBTSwgRG1pdHJ5IEFu aXBrbyA8RG1pdHJ5LkFuaXBrb0BtaWNyb3NvZnQuY29tPG1haWx0bzpEbWl0cnkuQW5pcGtvQG1p Y3Jvc29mdC5jb20+PiB3cm90ZToNCg0KPj5BIG1vcmUgcHJlY2lzZSBzdGF0ZW1lbnQgd291bGQg YmUgdGhhdCB0aGUgbnVtYmVyIG9mIHNvbGljaXRlZC1ub2RlIGdyb3VwcyBzY2FsZXMgbGluZWFy bHkgd2l0aCB0aGUgbnVtYmVyIG9mIElQdjYgYWRkcmVzc2VzIGFzc2lnbmVkIHRvIGhvc3RzLA0K DQpBZ3JlZWQuIEFuZCBnZW5lcmFsbHksIG51bWJlciBvZiBhZGRyZXNzZXMgY2FuIGJlIG1vcmUg dGhhbiAyLTMgKGJlY2F1c2Ugb2YgbXVsdGlwbGUgcHJlZml4ZXMsIGFuZCBiZWNhdXNlIG9mIG11 bHRpcGxlIHN1ZmZpeGVzIGR1ZSB0byBwcml2YWN5IGV4dGVuc2lvbnMpLg0KSW5kZWVkLiBCdXQg aW4gdGhlIGNvbW1vbiBjYXNlIG9mIGEgd2lmaSBuZXR3b3JrIHdoZXJlIGRldmljZXMgY29tZSBh bmQgZ28gZnJlcXVlbnRseSwgeW91J2xsIHR5cGljYWxseSBoYXZlIG9ubHkgYSBsaW5rLWxvY2Fs LCBhIGdsb2JhbCwgYW5kIG9uZSB0ZW1wb3JhcnkgYWRkcmVzcy4gSWYgeW91IHVzZSBFVUktNjQg dGhlIGxpbmstbG9jYWwgYW5kIHRoZSBnbG9iYWwgd2lsbCBiZSBvbiB0aGUgc2FtZSBncm91cC4N Cg0KDQpXZSBoYXZlIHJlY2VudGx5IHNlZW4gaXNzdWVzIGluIHNvbWUgQVBzLCB3aGVyZSB0aGV5 IHdlcmUgbm90IGFibGUgdG8gaGFuZGxlIG11bHRpcGxlIGFkZHJlc3NlcyBwZXIgaG9zdCwgYmVj YXVzZSBvZiBzb21lIHN0YXRlIG1haW50YWluZWQgcGVyIGhvc3QgKHRoYXQncyBub3QgYSBqdXN0 aWZpY2F0aW9uIHRoYXQgaG9zdCBzaG91bGQgbm90IGhhdmUgbXVsdGlwbGUgYWRkcmVzc2VzLCBi dXQgSSBqdXN0IHdhbnRlZCB0byBub3RlIHRoYXQgdG9kYXkgdGhlcmUgYXJlIGlzc3VlcyBpbiBz b21lIGNhc2VzIHJlbGF0ZWQgdG8gdGhhdCkuDQpXZSBzaG91bGQgY2xhcmlmeSB0aGF0IHN1Y2gg YmVoYXZpb3VyIGlzIGJyb2tlbiBhbmQgdGhhdCBzYXlpbmcsICJpdCB3b3JrcyBpbiBJUHY0LCBz byB3ZSBzaG91bGQganVzdCB1c2UgREhDUHY2IGZvciBhZGRyZXNzIGFzc2lnbm1lbnQgc28gdGhh dCB3ZSBjYW4gZm9yY2UgdGhlIGhvc3QgdG8gaGF2ZSBvbmx5IG9uZSBhZGRyZXNzIiBpcyBub3Qg YSBzb2x1dGlvbi4NCg== --_000_35d4e6f484974024bfe4e00b4e51ca8fSN2PR03MB077namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mZ3Q7Jmd0Ozwvc3Bhbj4gV2Ugc2hvdWxkIGNsYXJpZnkgdGhhdCBzdWNoIGJlaGF2 aW91ciBpcyBicm9rZW4gYW5kIHRoYXQgc2F5aW5nLCAmcXVvdDtpdCB3b3JrcyBpbiBJUHY0LCBz byB3ZSBzaG91bGQganVzdCB1c2UgREhDUHY2IGZvciBhZGRyZXNzIGFzc2lnbm1lbnQgc28gdGhh dCB3ZQ0KIGNhbiBmb3JjZSB0aGUgaG9zdCB0byBoYXZlIG9ubHkgb25lIGFkZHJlc3MmcXVvdDsg aXMgbm90IGEgc29sdXRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFncmVlIHdpdGggeW91LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBM b3JlbnpvIENvbGl0dGkgW21haWx0bzpsb3JlbnpvQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gRnJpZGF5LCBKYW51YXJ5IDE3LCAyMDE0IDExOjM3IEFNPGJyPg0KPGI+VG86PC9iPiBE bWl0cnkgQW5pcGtvPGJyPg0KPGI+Q2M6PC9iPiBPbGUgVHJvYW47IEluZy1XaGVyIENoZW47IDZt YW4gV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IE1MRCBzbm9vcGluZyBvZiBzb2xpY3RlZC1u b2RlIG11bHRpY2FzdCAoV2FzOiBSZTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1oYWxwZXJuLTZtYW4tbmQtcHJlLXJlc29sdmUtYWRkci0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgSmFuIDE3LCAyMDE0 IGF0IDExOjE0IEFNLCBEbWl0cnkgQW5pcGtvICZsdDs8YSBocmVmPSJtYWlsdG86RG1pdHJ5LkFu aXBrb0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+RG1pdHJ5LkFuaXBrb0BtaWNyb3Nv ZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxkaXYgbmFtZT0iZGl2dGFnZGVmYXVsdHdyYXBwZXIiPg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZndDsmZ3Q7PHNwYW4gc3R5bGU9ImNvbG9yOiMyODI4MjgiPkEgbW9yZSBwcmVjaXNlIHN0YXRl bWVudCB3b3VsZCBiZSB0aGF0IHRoZSBudW1iZXIgb2Ygc29saWNpdGVkLW5vZGUgZ3JvdXBzIHNj YWxlcyBsaW5lYXJseSB3aXRoIHRoZSBudW1iZXIgb2YgSVB2NiBhZGRyZXNzZXMgYXNzaWduZWQg dG8gaG9zdHMsJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHA+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMjgyODI4Ij5BZ3JlZWQuIEFuZCBnZW5lcmFsbHksIG51bWJlciBv ZiBhZGRyZXNzZXMgY2FuIGJlIG1vcmUgdGhhbiAyLTMgKGJlY2F1c2Ugb2YgbXVsdGlwbGUgcHJl Zml4ZXMsIGFuZCBiZWNhdXNlIG9mIG11bHRpcGxlIHN1ZmZpeGVzIGR1ZSB0byBwcml2YWN5IGV4 dGVuc2lvbnMpLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklu ZGVlZC4gQnV0IGluIHRoZSBjb21tb24gY2FzZSBvZiBhIHdpZmkgbmV0d29yayB3aGVyZSBkZXZp Y2VzIGNvbWUgYW5kIGdvIGZyZXF1ZW50bHksIHlvdSdsbCB0eXBpY2FsbHkgaGF2ZSBvbmx5IGEg bGluay1sb2NhbCwgYSBnbG9iYWwsIGFuZCBvbmUgdGVtcG9yYXJ5IGFkZHJlc3MuIElmIHlvdSB1 c2UgRVVJLTY0IHRoZSBsaW5rLWxvY2FsIGFuZCB0aGUgZ2xvYmFsIHdpbGwgYmUgb24gdGhlIHNh bWUgZ3JvdXAuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8 ZGl2IG5hbWU9ImRpdnRhZ2RlZmF1bHR3cmFwcGVyIj4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMyODI4MjgiPldlIGhhdmUgcmVjZW50bHkgc2VlbiBpc3N1ZXMgaW4gc29tZSBBUHMsIHdo ZXJlIHRoZXkgd2VyZSBub3QgYWJsZSB0byBoYW5kbGUgbXVsdGlwbGUgYWRkcmVzc2VzIHBlciBo b3N0LCBiZWNhdXNlIG9mIHNvbWUgc3RhdGUgbWFpbnRhaW5lZCBwZXIgaG9zdCAodGhhdCdzIG5v dCBhIGp1c3RpZmljYXRpb24gdGhhdCBob3N0IHNob3VsZA0KIG5vdCBoYXZlIG11bHRpcGxlIGFk ZHJlc3NlcywgYnV0IEkganVzdCB3YW50ZWQgdG8gbm90ZSB0aGF0IHRvZGF5IHRoZXJlIGFyZSBp c3N1ZXMgaW4gc29tZSBjYXNlcyByZWxhdGVkIHRvIHRoYXQpLjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Ugc2hvdWxkIGNsYXJpZnkgdGhhdCBz dWNoIGJlaGF2aW91ciBpcyBicm9rZW4gYW5kIHRoYXQgc2F5aW5nLCAmcXVvdDtpdCB3b3JrcyBp biBJUHY0LCBzbyB3ZSBzaG91bGQganVzdCB1c2UgREhDUHY2IGZvciBhZGRyZXNzIGFzc2lnbm1l bnQgc28gdGhhdCB3ZSBjYW4gZm9yY2UgdGhlIGhvc3QgdG8gaGF2ZSBvbmx5IG9uZSBhZGRyZXNz JnF1b3Q7IGlzIG5vdCBhIHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_35d4e6f484974024bfe4e00b4e51ca8fSN2PR03MB077namprd03pro_-- From brian.e.carpenter@gmail.com Fri Jan 17 11:59: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 38D391A1F61 for ; Fri, 17 Jan 2014 11:59:29 -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 IodjoLV7vthA for ; Fri, 17 Jan 2014 11:59:27 -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 256441A1F00 for ; Fri, 17 Jan 2014 11:59:27 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id rq2so4513931pbb.31 for ; Fri, 17 Jan 2014 11:59:14 -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=NjOHuzb6czPm3oETBOunz0YmEDDeUGls9Q6Go75Yb7g=; b=L9U6iDsnOr2z4NpwaWcafbHRga/xJX7EjSYSgJPvktCCghxU/LOLWoWwdkFZohw5EN DBDMqDvltGiqAubiqOa4vXF3I6dzO5TLxuOSDQz3vubOBM+KYtij9bLEI/5zQmoztMf5 Cei2H/6uz8uD4deOcseRPvF5PI2YzcYp061qlEz0G5XmOafAG8rAzO+oxYhJzvrHf7oF nd4M++kBNapoWHakIoZo0Y78WAIcHrvWIBwMmgoXFLx1M1f5Q8uy0pGuzGt2dPeCmFve 9eO0RKF00UpkW0/xmtU4nELH/paxCE8CPNodJMHvEPp0gULZS+ZF7HW3lVNy4TUgvEAC ynKg== X-Received: by 10.68.114.163 with SMTP id jh3mr4027529pbb.99.1389988754701; Fri, 17 Jan 2014 11:59:14 -0800 (PST) Received: from [192.168.178.23] (166.199.69.111.dynamic.snap.net.nz. [111.69.199.166]) by mx.google.com with ESMTPSA id kk1sm24912756pbd.22.2014.01.17.11.59.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Jan 2014 11:59:13 -0800 (PST) Message-ID: <52D98B95.3090507@gmail.com> Date: Sat, 18 Jan 2014 08:59:17 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christian Huitema Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] References: <52C9D788.8060606@gmail.com> <1389041504.19037.YahooMailNeo@web161905.mail.bf1.yahoo.com> <52CD7A93.4030908@gmail.com> <52CDA427.80906@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alexandru Petrescu , "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, 17 Jan 2014 19:59:29 -0000 Yes, Christian's explanation of "Why 128?" corresponds to what I remember (and of course there were also arguments for a variable length format, but that is another thread entireley). > Many examples show an 80 bit prefix and a 48 bit MAC address. Indeed - and the story about EUI-64 came a little later, after RFC 1884 and during the development of draft-ietf-ipngwg-addr-arch-v2. Some archive trawling suggests that Firewire addresses were first mentioned during an IPng Working Group interim meeting, February 27 & 28, 1997, Palo Alto, CA USA. The context was a discussion of the 8+8 proposal. https://www.sixxs.net/archive/docs/ipng-archives/ Brian On 17/01/2014 18:47, Christian Huitema wrote: >> But maybe someone who has Christian's book could send a paraphrase >> of his explanation. > > I have of course a few copies on my shelves. Mark ZZZ Smith is probably referring to the Chapter 4 of "IPv6, the new Internet Protocol," which was published in 1996. The chapter deals with "plug and play," and the first paragraph reads: > > "By the end of June 1994, the IPng saga was coming to a close. The IPng selection committee had almost made up its' mind. The choice had to be based on the SIPP proposal, but SIPP could not be bought lock, stock, and barrel. A substantial number of directorate members thought that the 64-bit addresses were too narrow, that they would not provide enough flexibility to implement proper routing protocols. There was a compromise in sight, if only the SIPP proponents would agree to increase the address size to 128 bits. The IETF decision process is based on building consensus, part of which implies polling opinion leaders. I was one of those leaders by this time, or so they thought, so they polled me. Would I accept inflating the address to 128 bits? I had publicly stated many times that 64 bits was more than enough and I could back my opinion with substantial mathematical analysis. However, I did not hesitate too long. Going to 128 bits was a little price to pay to reach conse nsus and save the Internet. Moreover, 128-bit addresses have a definite advantage. They have twice the width that routing procedures require, hence they make a lot of room avail-able for proper implementation of auto configuration procedures. " > > I then go on to explain how auto configuration works by concatenation of a network prefix and a unique identifier of the host, normally a MAC address. The 1996 version of the book was written before the ND specifications was finalized, and does not actually specify the 64 bit prefix size. Many examples show an 80 bit prefix and a 48 bit MAC address. > > -- Christian Huitema > > From lorenzo@google.com Fri Jan 17 14:50: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 E64621ACCFC for ; Fri, 17 Jan 2014 14:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, 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 6rlfI3N-95lc for ; Fri, 17 Jan 2014 14:49:59 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 65A8E1ACCF8 for ; Fri, 17 Jan 2014 14:49:59 -0800 (PST) Received: by mail-ig0-f177.google.com with SMTP id k19so2900133igc.4 for ; Fri, 17 Jan 2014 14:49:46 -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=bSjP7bFvMGTDmPABDxuonKYWHfALWhkLdrmBtjoEBZY=; b=f6zWdp0FTRueIjOMDcFU+uWmh18brKdQ0ZK50P06NzizlK5S1U5BEjRT5+H23/JP3g AX3yqw/+Pit35bB9s2sPQHDS2DWXo5Ngv6ZIoa0AFmumSqdAgbpKuaj9WT7BaVq52aF3 nOwvkVtpEMGVAva9zD5RXVxgl4l3kLLwj4oFZEnB2NySaOOFudHuCnb9zkL5hmawE8Xb U7Mw5Y1Mm6YoRCBB/fjbSIqy0X974mHHZWMu3gYTtxkbo2a9CU4ACeDMopKTX8QD8NhU VaBAv80YYCWbdG/qJfTCpcZbgBxJPvHxMFonOGqJZtiPQ7AcF9/h07f4C2zjhaOk4L2F qTrA== 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=bSjP7bFvMGTDmPABDxuonKYWHfALWhkLdrmBtjoEBZY=; b=aChUslTHxZkYPguMeSmBYSFJSxNQ7GDk8loF6rSdfEk/w/YcYsfVbgM6xY5sd/zDOq FccQjsCsg41DmYj5FGAD9cTbd96IWrb1qx6llUKd0TokuCzOaueFWmRirJioJNELLfIh 9cRQEBvFwB1vbxCltWqnE1yDqAIBeltmSHXikZeDobN25QuJV5h1va+y9YoLrhX0W6mI H31DWMUz0fsv4R2LNMFEOZdycphC8FWShLmdJHchXvXOhrDM1mFyuLCTMDSYv+Ep7JeM c/wFQnLLJOts8Caq9qTifziZB9guObmh1oAsS85Pe7bwmJLJYCjWXhzpwOp7oic6SBYL qbwg== X-Gm-Message-State: ALoCoQmZP/puCEtPgem6QfuDJiIkAXG42PbBWonNaQPu4vn29BXm9+/JJDbQZQaxIGiUGinOrJkiAeTFCJwhy6bkxtJDDjrQOzQnklNcIXQyTAb0PhkltTL+yqgMf29SzOXAoMWfrNUfO7Rei7ZOE3XUbS9B3F1YyMRGYvfB+5UwlXg0osYjZs6ycthCwpeWPspIwoVMXVnE X-Received: by 10.43.51.65 with SMTP id vh1mr4118591icb.24.1389998986587; Fri, 17 Jan 2014 14:49:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Fri, 17 Jan 2014 14:49:26 -0800 (PST) In-Reply-To: <52D96663.6060005@sonic.net> References: <52D96663.6060005@sonic.net> From: Lorenzo Colitti Date: Sat, 18 Jan 2014 07:49:26 +0900 Message-ID: Subject: Re: Reducing the battery impact of ND To: Erik Nordmark Content-Type: multipart/alternative; boundary=bcaec5299ad7d88aa604f0325bb7 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG , =?UTF-8?Q?Andrew_=F0=9F=91=BD_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: Fri, 17 Jan 2014 22:50:02 -0000 --bcaec5299ad7d88aa604f0325bb7 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 17, 2014 at 9:20 AM, Erik Nordmark wrote: > 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. > And if you work out the details on b) I suspect you'll find that to > completely avoid the periodic multicast RAs the routers need to know > whether hosts expect periodic RA as opposed to all the hosts doing the RS > restart. That would imply some more protocol change. > You don't need to avoid them. You just need to make them infrequent enough that they are not a substantial cause of power drain. I know from solid data that on a device like a mobile phone on a wifi network, an RA every 30 minutes is *way* down in the noise in terms of power consumption. (While "one RA every 3 seconds because the router sends a multicast RS to everyone every time a device joins the network" *does* have an impact). > And just to be perfectly clear, I don't think assuming (near) perfect MLD > snooping including in WiFi APs is undesirable. Hence my focus has been to > remove as much as possible of the ND multicasts including the DAD and NS > packets. > You don't need to do the snooping on the APs. You can do it on the client side, in the wifi firmware. The power savings between "received but filtered out in wifi firmware" and "received, passed to the main processor and ignored" are substantial; again, for a mobile phone on wifi, we have data on this. But my overall observation is that if we think we can fix (even a subset > of) this without a standards update, then we are just fooling ourselves. > It depends what sort of device you're talking about. If you're talking about a mobile phone, then we can fix it for sure. If you're talking about a sensor whose battery needs to last for months, then maybe not. But that's what we have 6LowPAN for. Cheers, Lorenzo --bcaec5299ad7d88aa604f0325bb7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 17, 2014 at 9:20 AM, Erik Nordmark <nordmark@sonic.net> wrote:
One of your "yes please" below is a change to ND - Andr= ew's b) about restarting RS would require a (small) standards update.

We should try to get that into draft-6man-= resilient-rs.
=C2=A0
And if you work out the details on b) I= suspect you'll find that to completely avoid the periodic multicast RA= s the routers need to know whether hosts expect periodic RA as opposed to a= ll the hosts doing the RS restart. That would imply some more protocol chan= ge.

You don't need to avoid them. You just= need to make them infrequent enough that they are not a substantial cause = of power drain. I know from solid data that on a device like a mobile phone= on a wifi network, an RA every 30 minutes is *way* down in the noise in te= rms of power consumption. (While "one RA every 3 seconds because the r= outer sends a multicast RS to everyone every time a device joins the networ= k" *does* have an impact).
=C2=A0
And just to be perfectly clear, I don't thin= k assuming (near) perfect MLD snooping including in WiFi APs is undesirable= . Hence my focus has been to remove as much as possible of the ND multicast= s including the DAD and NS packets.

You don't need to do the snooping on t= he APs. You can do it on the client side, in the wifi firmware. The power s= avings between "received but filtered out in wifi firmware" and &= quot;received, passed to the main processor and ignored" are substanti= al; again, for a mobile phone on wifi, we have data on this.

But my overall observation is that if we think we = can fix (even a subset of) this without a standards update, then we are jus= t fooling ourselves.

It depends what sort of device you&#= 39;re talking about. If you're talking about a mobile phone, then we ca= n fix it for sure. If you're talking about a sensor whose battery needs= to last for months, then maybe not. But that's what we have 6LowPAN fo= r.

Cheers,
Lorenzo
--bcaec5299ad7d88aa604f0325bb7-- From markzzzsmith@yahoo.com.au Fri Jan 17 16:00: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 076311AD190 for ; Fri, 17 Jan 2014 16:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.549 X-Spam-Level: *** X-Spam-Status: No, score=3.549 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, MANGLED_SAVELE=2.3, 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 4mFPw8lsD0Wv for ; Fri, 17 Jan 2014 16:00:43 -0800 (PST) Received: from nm25-vm1.bullet.mail.bf1.yahoo.com (nm25-vm1.bullet.mail.bf1.yahoo.com [98.139.212.155]) by ietfa.amsl.com (Postfix) with ESMTP id 78D9C1A1521 for ; Fri, 17 Jan 2014 16:00:43 -0800 (PST) Received: from [66.196.81.174] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 18 Jan 2014 00:00:30 -0000 Received: from [98.139.212.249] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 18 Jan 2014 00:00:30 -0000 Received: from [127.0.0.1] by omp1058.mail.bf1.yahoo.com with NNFMP; 18 Jan 2014 00:00:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 525470.54262.bm@omp1058.mail.bf1.yahoo.com Received: (qmail 60897 invoked by uid 60001); 18 Jan 2014 00:00:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1390003230; bh=+w+7GmBbVH1J/qt2M65EhJBbd/PDxDMZz7rEGuMIKyg=; 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=L9vh0MPCB7IbNkI6CCoyZsXQDz4CNv/w7VJgoYJFIZnqQF/nQd5SAZjU2nPd0oXEooTOao0ZbxVP6pA3ApJ5CEsuTgJQm2nQzpXFpDYk4jEj8T14i4zypVudMqSDMZFp3eUG4zkwUkjdGfI20NEWfTFT5TaNjzWbZ3AE6kSqjLw= 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=WOcSwZRd8WB3HvBGhUeE6l35TLOqbXBmWdfUGTv/ZWG4xCXSAT4ebiLIp5F0NWBoLEo/tYd2hadFRinwktkwnukm8Fcge8cjraYxVwJN63QcI4lmRm8hShPQcxgKRKdRy0kcKxoIWHNK2pxt4AkBXieKgMX8vcnN4fT39vYw67k=; X-YMail-OSG: .K4e2LkVM1lLujjI3ncxtyYBWDk.lWj8l0N23C1_SI_f5Fb cqnnUYtHh9rfGMxZJz6Vb_w4CZ7DkI2dVKMrFpZBoNAwNnxqVIk4zoRITyur RFM8NWRUgH4Dzq47txh02bCB6H1awTKEHJMzLCysa6VpdLhJ51Vs36Ut8Sgy D.FBam0KH2ire.q6dMTbG.qCxoPmatSJSAp7GEo1V0SKq9MkHMkDwUDtl_H. erenJeG6VseXKGy8y.3.Ou884jbbYJm0MG7nWdlA2lIOKK_EP6ZdaYgJNk0p K9doDhBHr4AwsKhV2CtL82tKaldaJb2ApOelQ9GH_ewjyIVSlbZUaUzHevf. Xr0gzG4PkS9JKgsXBvxRLaHEiyDdVGb7KtRbmK3aiuLrg.nlwfho0LiGjZ0h jFBPYPj_Drqt2T2HIXaigssArHBce5rXQfFSLaCCPEVWBespIkrgDjB4Qxvp mNaB6djjTeKnP_VWgGSillJwqmK5h2ssg6ek6DrqIpYzNnNSPvx04FBOyOdV cgNlkjjKbdjDgGcYwhlRaAGZviMdRQzH5dMzvTVlXvaC_8s.DpmHBc3aFFtN q3a84psEbxXFibh_xnaVm Received: from [150.101.221.237] by web161905.mail.bf1.yahoo.com via HTTP; Fri, 17 Jan 2014 16:00:30 PST X-Rocket-MIMEInfo: 002.001, SGksCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQG1pY3Jvc29mdC5jb20.Cj4gVG86IEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20.OyBBbGV4YW5kcnUgUGV0cmVzY3UgPGFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb20.Cj4gQ2M6ICJpcHY2QGlldGYub3JnIiA8aXB2NkBpZXRmLm9yZz4KPiBTZW50OiBGcmlkYXksIDE3IEphbnVhcnkgMjAxNCA0OjQ3IFBNCj4gU3ViamVjdDogUkU6IFtGd2Q6IEkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.173.622 References: <52C9D788.8060606@gmail.com> <1389041504.19037.YahooMailNeo@web161905.mail.bf1.yahoo.com> <52CD7A93.4030908@gmail.com> <52CDA427.80906@gmail.com> Message-ID: <1390003230.41161.YahooMailNeo@web161905.mail.bf1.yahoo.com> Date: Fri, 17 Jan 2014 16:00:30 -0800 (PST) From: Mark ZZZ Smith Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt] To: Christian Huitema , Brian E Carpenter , Alexandru Petrescu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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, 18 Jan 2014 00:00:45 -0000 Hi,=0A=0A=0A----- Original Message -----=0A> From: Christian Huitema =0A> To: Brian E Carpenter ; = Alexandru Petrescu =0A> Cc: "ipv6@ietf.org" <= ipv6@ietf.org>=0A> Sent: Friday, 17 January 2014 4:47 PM=0A> Subject: RE: [= Fwd: I-D Action: draft-carpenter-6man-why64-00.txt]=0A> =0A> =0A>> But may= be someone who has Christian's book could send a paraphrase=0A>> of his ex= planation.=0A> =0A> I have of course a few copies on my shelves. Mark ZZZ S= mith is probably =0A> referring to the Chapter 4 of "IPv6, the new Internet= Protocol," which =0A> was published in 1996.=0A=0AThe edition I have is th= e 1998 2nd edition, and the text which I found most interesting regarding t= he history of the address size choice was in the Points of Controversy sect= ion, starting on page 77, of the "Routing and Addressing" chapter, which de= scribed considerations such as geographic based addressing, variable length= addressing and the 8+8 proposal.=0A=0AI'd still recommend people get the b= ook even though it was last published in 1998, because the "Points of Contr= oversy" sections at the end of each chapter provide so much insight into wh= y IPv6 was designed the way it was. I've found the "whys" and "why nots" of= the designs of things to be as useful if not sometimes more useful than th= e "whats", and this is one of the few networking books that I have that cap= tures quite a lot of the "whys". (Radia Perlman's "Interconnections", 2nd e= dition is another one.)=0A=0A=0ARegards,=0AMark.=0A=0A=0A> The chapter deal= s with "plug and play," and the =0A> first paragraph reads:=0A> =0A> "By th= e end of June 1994, the IPng saga was coming to a close. The IPng =0A> sele= ction committee had almost made up its' mind. The choice had to be based = =0A> on the SIPP proposal, but SIPP could not be bought lock, stock, and ba= rrel. A =0A> substantial number of directorate members thought that the 64-= bit addresses were =0A> too narrow, that they would not provide enough flex= ibility to implement proper =0A> routing protocols. There was a compromise = in sight, if only the SIPP proponents =0A> would agree to increase the addr= ess size to 128 bits. The IETF decision process =0A> is based on building c= onsensus, part of which implies polling opinion leaders. I =0A> was one of = those leaders by this time, or so they thought, so they polled me. =0A> Wou= ld I accept inflating the address to 128 bits? I had publicly stated many = =0A> times that 64 bits was more than enough and I could back my opinion wi= th =0A> substantial mathematical analysis. However, I did not hesitate too = long. Going =0A> to 128 bits was a little price to pay to reach consensus a= nd sa=0A> ve the Internet. Moreover, 128-bit addresses have a definite adva= ntage. They =0A> have twice the width that routing procedures require, henc= e they make a lot of =0A> room avail-able for proper implementation of auto= configuration procedures. =0A> "=0A> =0A> I then go on to explain how auto= configuration works by concatenation of a =0A> network prefix and a unique= identifier of the host, normally a MAC address. The =0A> 1996 version of t= he book was written before the ND specifications was finalized, =0A> and do= es not actually specify the 64 bit prefix size. Many examples show an 80 = =0A> bit prefix and a 48 bit MAC address.=0A> =0A> =0A> -- Christian Huitem= a=0A> =0A> =0A> -----------------------------------------------------------= ---------=0A> IETF IPv6 working group mailing list=0A> ipv6@ietf.org=0A> Ad= ministrative Requests: https://www.ietf.org/mailman/listinfo/ipv6=0A> -----= ---------------------------------------------------------------=0A> From markzzzsmith@yahoo.com.au Fri Jan 17 16:14: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 CB2BC1ACC8A for ; Fri, 17 Jan 2014 16:14:05 -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 hurx8FlUi9gB for ; Fri, 17 Jan 2014 16:14:04 -0800 (PST) Received: from nm26-vm0.bullet.mail.bf1.yahoo.com (nm26-vm0.bullet.mail.bf1.yahoo.com [98.139.213.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8C17D1A8028 for ; Fri, 17 Jan 2014 16:14:04 -0800 (PST) Received: from [66.196.81.172] by nm26.bullet.mail.bf1.yahoo.com with NNFMP; 18 Jan 2014 00:13:51 -0000 Received: from [98.139.212.193] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 18 Jan 2014 00:13:51 -0000 Received: from [127.0.0.1] by omp1002.mail.bf1.yahoo.com with NNFMP; 18 Jan 2014 00:13:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 662851.16872.bm@omp1002.mail.bf1.yahoo.com Received: (qmail 68595 invoked by uid 60001); 18 Jan 2014 00:13:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1390004031; bh=zrzcjxpYOVzAlAaO11cVkmYu30GEzWmwIYtFL/i2nS0=; 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=Q9NTKTeyPkQcG+O2tzRjyfQTFQt5SuUzJbfuq08iBHYvYxWtZIf5t7ZQR3mpeFzaN+b/weyiaizc42J74FlJa+zitdx0Od6Rs2zlMcl/7qM891nIL+igX14iqQeF+0+1/1rbTUo1Z5mlGV5IWIPFwYkaKAarnNgGv8zRT9FTQ9A= 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=xR6QHuPoAn7bcxWGvYGJwEQIbBI8qtk3WSISU4RX9IktaOdwG6JQkiP7RVsMdSXw/pS6qf6OaOt9O/WUdVdxzlK+yH4knJkCDDXMESnlyrLjAvIQdtLDamKNGC9v7o9UXltkK/1olZZwq7Di8oBG4k2ZPtRS/VoMBvd5VHu06S0=; X-YMail-OSG: K8lsvKMVM1kmJDW20cS8jUKFr6bVnOy.RuBMUN8S0n61qxY lrPLnLbC8b_3EZ_tmo66MmPXYFsDls8ZWb.7rnJTpTO5fX3dyCPtRJbM2J1Y DfZU5tK3BRJk5ab2vDgqdn6JEV2w19fhJC0rnlkepG1EGmcjfE4kJOvUIisF XznEjF80YEYDpvTnRmfUaMj6vb9Hdfc19cnzyNoSandh2TLwO4w5mwBYtaQB pDo0BWNAWs19M8MHekuwS90fTyb.vCzGVtn._ERlWXqnUhKfAxVb0nzgZUuh FCu6qbcPnw0dsIfoi3NYKUJIlFWoP7jf4QGiZxjTJyFLhsxusGb407YzEDGz LVdaaZ602zHkjuTl5U5nd4bfn7O6zYA5tyCCIXoeLMAbIogD8C9oc7pSwhTc T_qEBl_IAVUW4eX9tfJQ6igBRSr8imLkJPfozZFVfbZeDEM6SDHMwvEaFd28 7RSsr17cAuqtVsvf1.QbcifjJvYgAjWqTmZc2wfMAPDtWfX9rY.eIfEtfsWp 7EBPACKMMiRog5ZQA_FWcK0dCebZ9ZSdJGSWSZhBsPe4t.Sp7ntZ7RpRp8cG A20TkHeHcBNaUcHIDv7dmifw- Received: from [150.101.221.237] by web161903.mail.bf1.yahoo.com via HTTP; Fri, 17 Jan 2014 16:13:51 PST X-Rocket-MIMEInfo: 002.001, CgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4KPlRvOiBEbWl0cnkgQW5pcGtvIDxEbWl0cnkuQW5pcGtvQG1pY3Jvc29mdC5jb20.IAo.Q2M6IDZtYW4gV0cgPGlwdjZAaWV0Zi5vcmc.OyBJbmctV2hlciBDaGVuIDxpbmctd2hlci5jaGVuQGVyaWNzc29uLmNvbT4gCj5TZW50OiBTYXR1cmRheSwgMTggSmFudWFyeSAyMDE0IDY6MzYgQU0KPlN1YmplY3Q6IFJlOiBNTEQgc25vb3Bpbmcgb2Ygc29saWN0ZWQtbm8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.173.622 References: <20140111004402.10451.90724.idtracker@ietfa.amsl.com> <72381AF1F18BAE4F890A0813768D992817FCA84E@sdcexchms.au.logicalis.com> <892FB91E-311D-4A50-A38B-4972F70847AB@employees.org> <2c30d818adc447b2a0ca3a7f0556ee65@SN2PR03MB077.namprd03.prod.outlook.com> <5e8d384f3009492fbe3992d82176aa26@SN2PR03MB077.namprd03.prod.outlook.com> Message-ID: <1390004031.1656.YahooMailNeo@web161903.mail.bf1.yahoo.com> Date: Fri, 17 Jan 2014 16:13:51 -0800 (PST) From: Mark ZZZ Smith Subject: Re: MLD snooping of solicted-node multicast (Was: Re: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt To: Lorenzo Colitti , Dmitry Anipko In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ing-Wher Chen , 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: Sat, 18 Jan 2014 00:14:06 -0000 =0A=0A=0A=0A=0A>________________________________=0A> From: Lorenzo Colitti = =0A>To: Dmitry Anipko =0A= >Cc: 6man WG ; Ing-Wher Chen = =0A>Sent: Saturday, 18 January 2014 6:36 AM=0A>Subject: Re: MLD snooping of= solicted-node multicast (Was: Re: New Version Notification for draft-halpe= rn-6man-nd-pre-resolve-addr-00.txt=0A> =0A>=0A>=0A>On Fri, Jan 17, 2014 at = 11:14 AM, Dmitry Anipko wrote:=0A>=0A>>>A mor= e precise statement would be that the number of solicited-node groups scale= s linearly with the number of IPv6 addresses assigned to hosts,=A0=0A>>Agre= ed. And generally, number of addresses can be more than 2-3 (because of mul= tiple prefixes, and because of multiple suffixes due to privacy extensions)= .=0A>Indeed. But in the common case of a wifi network where devices come an= d go frequently, you'll typically have only a link-local, a global, and one= temporary address. If you use EUI-64 the link-local and the global will be= on the same group.=0A>=A0=0A>We have recently seen issues in some APs, whe= re they were not able to handle multiple addresses per host, because of som= e state maintained per host (that's not a justification that host should no= t have multiple addresses, but I just wanted to note that today there are i= ssues in some cases related to that).=0A>>=0A>We should clarify that such b= ehaviour is broken and that saying, "it works in IPv4, so we should just us= e DHCPv6 for address assignment so that we can force the host to have only = one address" is not a solution.=0A>=0A=0AAnd remind them that all interface= s are to also have link-local addresses (RFC4291), and link-local addresses= are candidates for use by applications (RFC4007, RFC6724). From nordmark@acm.org Fri Jan 17 21:02: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 5EC071ADBFF for ; Fri, 17 Jan 2014 21:02:05 -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 Hp3uw2XR1thm for ; Fri, 17 Jan 2014 21:02:04 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 025F91ADD02 for ; Fri, 17 Jan 2014 21:02:03 -0800 (PST) Received: from [10.0.1.44] (184-23-158-201.dsl.dynamic.sonic.net [184.23.158.201]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s0I51kVi028038 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 17 Jan 2014 21:01:47 -0800 Message-ID: <52DA0ABA.8030903@acm.org> Date: Fri, 17 Jan 2014 21:01:46 -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: Lorenzo Colitti Subject: Re: Reducing the battery impact of ND References: <52D96663.6060005@sonic.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;nk2rof1/4xG7TjqjisUCUQ== M;Fgcuov1/4xG7TjqjisUCUQ== Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG , =?UTF-8?B?QW5kcmV3IPCfkb0gWW91cnRjaGVua28=?= 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, 18 Jan 2014 05:02:05 -0000 On 1/17/14 2:49 PM, Lorenzo Colitti wrote: > On Fri, Jan 17, 2014 at 9:20 AM, Erik Nordmark > wrote: > > 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. Erik > And if you work out the details on b) I suspect you'll find that to > completely avoid the periodic multicast RAs the routers need to know > whether hosts expect periodic RA as opposed to all the hosts doing > the RS restart. That would imply some more protocol change. > > > You don't need to avoid them. You just need to make them infrequent > enough that they are not a substantial cause of power drain. I know from > solid data that on a device like a mobile phone on a wifi network, an RA > every 30 minutes is *way* down in the noise in terms of power > consumption. (While "one RA every 3 seconds because the router sends a > multicast RS to everyone every time a device joins the network" *does* > have an impact). > > And just to be perfectly clear, I don't think assuming (near) > perfect MLD snooping including in WiFi APs is undesirable. Hence my > focus has been to remove as much as possible of the ND multicasts > including the DAD and NS packets. > > > You don't need to do the snooping on the APs. You can do it on the > client side, in the wifi firmware. The power savings between "received > but filtered out in wifi firmware" and "received, passed to the main > processor and ignored" are substantial; again, for a mobile phone on > wifi, we have data on this. > > > But my overall observation is that if we think we can fix (even a > subset of) this without a standards update, then we are just fooling > ourselves. > > > It depends what sort of device you're talking about. If you're talking > about a mobile phone, then we can fix it for sure. If all you want is to max the RA timers to > 30 minutes then you don't need a standards change. But the other things that have been discussed seem to require an update to RFC 4861. FWIW I don't have a problem with an opt-in update to 4861. I even think efficient-nd is the way to go because it reduces overall ND multicast traffic and not just your narrow focus on mobile phone battery life. Erik > If you're talking > about a sensor whose battery needs to last for months, then maybe not. > But that's what we have 6LowPAN for. > > Cheers, > Lorenzo From nordmark@acm.org Fri Jan 17 21:02: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 909EC1ADE71 for ; Fri, 17 Jan 2014 21:02:22 -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 hHy1Vd4Bip3E for ; Fri, 17 Jan 2014 21:02: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 43BC91ADDD1 for ; Fri, 17 Jan 2014 21:02:20 -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 s0I51tr5017233 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 17 Jan 2014 21:01:56 -0800 Message-ID: <52DA0AC3.3090607@acm.org> Date: Fri, 17 Jan 2014 21:01:55 -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: Greg Daley , "'Ing-Wher Chen'" , "ipv6@ietf.org" Subject: Re: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt References: <20140111004402.10451.90724.idtracker@ietfa.amsl.com> <72381AF1F18BAE4F890A0813768D992817FCA84E@sdcexchms.au.logicalis.com> In-Reply-To: <72381AF1F18BAE4F890A0813768D992817FCA84E@sdcexchms.au.logicalis.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;mtH9pv1/4xGuvoIY+v0w6Q== M;bgwrp/1/4xGuvoIY+v0w6Q== 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, 18 Jan 2014 05:02:22 -0000 Greg, In addition to your concern about multicast snooping environments, the DAD packets are not reliably delivered. If e.g. there is a short WiFi drop, the spanning tree is reconverging, etc then the single transmitted DAD packet will not be received. Thus as best this will collect some entries in the neighbor cache. It isn't at all clear when a node should discard entries from its neighbor cache. That is potentially problematic when there are lots of devices that pick new temporary IPv6 addresses each time they power on since that will force routers to sooner or later discard entries from the neighbor cache. The routers would have to guess which addresses might still be assigned to the hosts. Thus all in all this is not a robust approach to the problem. Erik On 1/16/14 6:14 PM, Greg Daley wrote: > Hi Helen, > > I've got a couple of issues with the draft apart from IPR. > > It seems that principal assumption is that off-link flooding can occur due to sending packets to unknown host destinations on a subnet, and reuses the mandatory DAD-NS transmission as a proof-of-life for an address to avoid packets being transmitted on the link. > > Firstly, I think there could be simpler mitigation techniques for this: > 1/ Mandate DHCP for global prefixes - which ensures that the devices send packets to routers on the link to keep their address (and limit unregistered address lookups) > 2/ Treat on-link generated ND Cache entries (or entries which have previously been REACHABLE) as different to off-link generated (rate limit). > > In that case, the ND resolution behaviour for incomplete off-link is reduced and live communications cannot be impacted. There is still a potential DoS issue for initiating communications to quiet servers, but if the on-link server has ever talked to the router it could still have a STALE NCE. > > Secondly, the proposal assumes that DAD-NS packets are visible to all devices on the link, whereas they aren't in a Multicast-snooped environment. > > This implicitly requires that the router is assigned to an all-multi interface on the switch infrastructure, which it may be (but this isn't stated). It also negates the general applicability of this to hosts (rather than routers). > > Neighbour Solicitation messages for incomplete entries (per RFC 4861 S7.2.2) will be dropped by the snooping switches if there is no Multicast subscriber for the solicited nodes' multicast address. Not only is this a mitigation of the potential attack, but also indicates an alternative for non-snooping networks: > > 3/ Monitor the solicited nodes' addresses in the MLD querier router, and do not transmit an NS from off-link for an incomplete address unless someone is listening. > > > So I guess my comment is that we have two other potential solutions for mitigating transmission of off-link initiated NS's ( 1- Use DHCP bindings and 3 - MLD Solicited Nodes'), and some fair ideas for mitigating resource challenges in the ND engine (2), and decreased applicability in multicast snoop environments. > > Can you tell us why we should use this encumbered solution? > > Sincerely, > > Greg Daley > gdaley@au.logicalis.com > > > > > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ing-Wher Chen > Sent: Tuesday, 14 January 2014 9:53 AM > To: ipv6@ietf.org > Subject: RE: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt > > Please note that we're actively working with Ericsson's legal department on an IPR disclosure regarding the draft. > > Thanks, > Helen > > -----Original Message----- > From: Ing-Wher Chen > Sent: Monday, January 13, 2014 2:37 PM > To: 'ipv6@ietf.org' > Subject: FW: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt > > Hello, > > The informational draft below documents Ericsson's solution, deployed since early 2013, regarding Mikael's concern in the recent discussion about ND denial-of-service attacks. The draft also elaborates on Lorenzo's point regarding discovering neighbors based on DAD-NS packets. > > Thanks, > Helen > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, January 10, 2014 4:44 PM > To: Joel Halpern; Ing-Wher Chen; Joel Halpern; Ing-Wher Chen > Subject: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt > > > A new version of I-D, draft-halpern-6man-nd-pre-resolve-addr-00.txt > has been successfully submitted by I. Chen and posted to the IETF repository. > > Name: draft-halpern-6man-nd-pre-resolve-addr > Revision: 00 > Title: Triggering ND Address Resolution on Receiving DAD-NS > Document date: 2014-01-10 > Group: Individual Submission > Pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-halpern-6man-nd-pre-resolve-addr-00.txt > Status: https://datatracker.ietf.org/doc/draft-halpern-6man-nd-pre-resolve-addr/ > Htmlized: http://tools.ietf.org/html/draft-halpern-6man-nd-pre-resolve-addr-00 > > > Abstract: > This draft proposes a new optional event to trigger address > resolution using IPv6 Neighbor Discovery. This helps optimize router > performance, and can help mitigate certain potential ND-related > denial-of-service attacks. Upon receiving a DAD-NS message, the > neighbor solicitation message used to detect duplicate addresses, if > the target address encoded in the DAD-NS is not a duplicate address, > the receiving device responds by triggering address resolution for > the target address in the DAD-NS, in preparation for expectant future > communication with the sending device. > > > > > 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 markzzzsmith@yahoo.com.au Sat Jan 18 00:58: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 264541ADE87 for ; Sat, 18 Jan 2014 00:58:43 -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 9bAceL3fQ8V0 for ; Sat, 18 Jan 2014 00:58:42 -0800 (PST) Received: from nm18-vm4.bullet.mail.ne1.yahoo.com (nm18-vm4.bullet.mail.ne1.yahoo.com [98.138.91.178]) by ietfa.amsl.com (Postfix) with ESMTP id F33441ADDCA for ; Sat, 18 Jan 2014 00:58:41 -0800 (PST) Received: from [98.138.101.132] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jan 2014 08:58:29 -0000 Received: from [98.138.86.157] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jan 2014 08:58:29 -0000 Received: from [127.0.0.1] by omp1015.mail.ne1.yahoo.com with NNFMP; 18 Jan 2014 08:58:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 113366.65889.bm@omp1015.mail.ne1.yahoo.com Received: (qmail 91642 invoked by uid 60001); 18 Jan 2014 08:58:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1390035509; bh=NplnEFOx5RAE8rq4xW3cdDASlBphh7/p8NszOS1XcuI=; 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=mT87r4kikfckhyyFopPRFrVpeFtsqmaB10JbGNw5Z6MTz6hiFi2eHvYs9kh+qqrXNnu6StYC1lQGBFSykvZ+0IZ+/yCjrudU97Vg7omDOxfSgWzc19F4C4nj/z3yKF/VczATb7U5kxnxrk1vLxpEi2C2HkcmJcaYeCeuP6t+P6w= 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=OAwwGZBdBTH4jeASAJT1aW30N+i+bIzCHQrQZneDT6u5wlXDJkFhv+Ngxn+vkelqFtjRFGWoOXtFybT8Y2RUEk9MAFkwiLPJCFkpmmtSbp6hCRgB0FmEam3ELdxSyKq2IfWemjrLCWi1czWD26rB/fWpNYblR6P7IIl/CkFXx9Y=; X-YMail-OSG: mvXTV.UVM1lL28XbQSwalD6GVkuryL6n2DXfFRYy6Epd57v R3PMY2xKmFmOeDDEASlYoNEVg8Bbgw2ufVOFaxnalJVrlxua7EvudN1jPdXX wgShSro8_UqrlkVI66CvafzfWOAP1JICCsJ5NZT.HEEGjvy4QOURuj9BFie_ dIbYxbrm7c21OjJ8LLYi6TW_n0HgYwlVpOhGpspU7FmhVDuXaPo8fnvh0..G lagO.0ia3W_RlSWrO_k66BqCT3WlP33.eVhpfqL6fRPy1dyIYSqwNWfE.I6S nabEqJZWk99CTTkvda1CANYs1OuK4AAmaRyi4lb0QPJrufE1SuEZH9BRHTTO s_Ecgf5024c2_MHTYwFmBicXcPzTfZGgKWjBBAB7U.oDeOXpC7DsKbud3Qcp FJPERjxH2VECJbjqQLWggxpuvEdvo9Yn7BbojRI1hLOn_hrkxjcUONMCOSR8 gaf8dGcrsSz2Mru6hvnh1Gft5HTO1Mp9S4QuDsV_.3QRgFqJp2kuAfXyktTc HTbQDl8UlF6zhzcByBPhDjtYKdBYlA4eG0iFQZUJUjKKptqiunyRHntst5Qb TVn0TYPZ7qZBnsSlTHH.fd9jmG_Cmdw-- Received: from [150.101.221.237] by web120503.mail.ne1.yahoo.com via HTTP; Sat, 18 Jan 2014 00:58:28 PST X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBHcmVnIERhbGV5IDxnZGFsZXlAYXUubG9naWNhbGlzLmNvbT4KPiBUbzogJ0luZy1XaGVyIENoZW4nIDxpbmctd2hlci5jaGVuQGVyaWNzc29uLmNvbT47ICJpcHY2QGlldGYub3JnIiA8aXB2NkBpZXRmLm9yZz4KPiBDYzogCj4gU2VudDogRnJpZGF5LCAxNyBKYW51YXJ5IDIwMTQgMToxNCBQTQo.IFN1YmplY3Q6IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhhbHBlcm4tNm1hbi1uZC1wcmUtcmVzb2x2ZS1hZGQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.173.622 References: <20140111004402.10451.90724.idtracker@ietfa.amsl.com> <72381AF1F18BAE4F890A0813768D992817FCA84E@sdcexchms.au.logicalis.com> Message-ID: <1390035508.23310.YahooMailNeo@web120503.mail.ne1.yahoo.com> Date: Sat, 18 Jan 2014 00:58:28 -0800 (PST) From: Mark ZZZ Smith Subject: Re: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt To: Greg Daley , 'Ing-Wher Chen' , "ipv6@ietf.org" In-Reply-To: <72381AF1F18BAE4F890A0813768D992817FCA84E@sdcexchms.au.logicalis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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, 18 Jan 2014 08:58:43 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Greg Daley =0A> To: 'Ing-Wher Chen' ; "ipv6@ie= tf.org" =0A> Cc: =0A> Sent: Friday, 17 January 2014 1:14 PM= =0A> Subject: RE: New Version Notification for draft-halpern-6man-nd-pre-re= solve-addr-00.txt=0A> =0A> Hi Helen,=0A> =0A=0A=0A> =0A> 3/ Monitor t= he solicited nodes' addresses in the MLD querier router, and do =0A> not tr= ansmit an NS from off-link for an incomplete address unless someone is =0A>= listening.=0A>=0A=0ASo I've been thinking for the last few months that thi= s method could be a useful further mitigation to off-link ND cache attacks = for routers. I've been writing something up which I've been planning to fin= ish and post in the next week or so.=0A=0AI think it could be fairly effect= ive - there are a total possible 2^24 solicited-node multicast groups on a = link, where as there will only be as many present ones as there are IIDs wi= th unique lower 24 bits. For most subnets I think that will number in the o= rder of 10s or 100s, and perhaps on rare occasions in the low 1000s. So NSe= s would only be necessary for e.g. 1000/2^24 portion of the unicast address= space, otherwise the packets that would trigger them can be dropped (or pe= rhaps sent to an RFC6018 greynet collector).=0A=0AA neighbor cache attack i= s likely to be still be possible for the 2^40 portions of unicast address s= pace covered by each of the the present solicited-multicast groups, however= Fernando's Stable/Opaque IID draft would make them harder to find, even th= ough it will increase the number of them, as there is an unique Opaque IID = per prefix.=0A=0AAll routers listening to MLD track group membership, not j= ust the MLD querier, so all routers on the link could implement this method= .=0A=0ARegards,=0AMark. From alexandru.petrescu@gmail.com Sun Jan 19 06:10: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 926051AD68A for ; Sun, 19 Jan 2014 06:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.717 X-Spam-Level: ** X-Spam-Status: No, score=2.717 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, 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 foGJAFhWFkCR for ; Sun, 19 Jan 2014 06:10:49 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by ietfa.amsl.com (Postfix) with ESMTP id AC4641ACCE5 for ; Sun, 19 Jan 2014 06:10:46 -0800 (PST) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 679A5D480DD for ; Sun, 19 Jan 2014 15:10:29 +0100 (CET) Message-ID: <52DBDCD3.6010600@gmail.com> Date: Sun, 19 Jan 2014 15:10:27 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: 6man Subject: Update about draft-petrescu-ipv6-over-80211p-01.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Antivirus: avast! (VPS 140119-0, 19/01/2014), Outbound message X-Antivirus-Status: Clean 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, 19 Jan 2014 14:10:50 -0000 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 =E9lectronique ne contient aucun virus ou logiciel malveillant = parce que la protection avast! Antivirus est active. http://www.avast.com From gdaley@au.logicalis.com Sun Jan 19 14:50: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 753371A1F20 for ; Sun, 19 Jan 2014 14:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.045 X-Spam-Level: X-Spam-Status: No, score=-0.045 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.538, 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 NR-C9N0SbzPo for ; Sun, 19 Jan 2014 14:50:29 -0800 (PST) Received: from smtp1.au.logicalis.com (smtp1.au.logicalis.com [203.8.7.132]) by ietfa.amsl.com (Postfix) with ESMTP id 20C501AE05F for ; Sun, 19 Jan 2014 14:50:28 -0800 (PST) Received-SPF: None (smtp1.au.logicalis.com: no sender authenticity information available from domain of gdaley@au.logicalis.com) identity=mailfrom; client-ip=203.8.7.161; receiver=smtp1.au.logicalis.com; envelope-from="gdaley@au.logicalis.com"; x-sender="gdaley@au.logicalis.com"; x-conformance=spf_only Received-SPF: None (smtp1.au.logicalis.com: no sender authenticity information available from domain of postmaster@sdcexchht.au.logicalis.com) identity=helo; client-ip=203.8.7.161; receiver=smtp1.au.logicalis.com; envelope-from="gdaley@au.logicalis.com"; x-sender="postmaster@sdcexchht.au.logicalis.com"; x-conformance=spf_only Received: from unknown (HELO sdcexchht.au.logicalis.com) ([203.8.7.161]) by smtp1.au.logicalis.com with ESMTP; 20 Jan 2014 09:56:23 +1100 Received: from SDCEXCHMS.au.logicalis.com ([10.18.196.50]) by sdcexchht.au.logicalis.com ([fe80::68b7:8880:fefb:f742%12]) with mapi id 14.02.0347.000; Mon, 20 Jan 2014 09:50:12 +1100 From: Greg Daley To: 'Mark ZZZ Smith' , 'Ing-Wher Chen' , "ipv6@ietf.org" Subject: RE: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt Thread-Topic: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt Thread-Index: AQHPDmY2hGYF66RRbk+N6Vv6p523J5qDMmwwgAATMeCABOYbYIABVfwAgAMsKbA= Date: Sun, 19 Jan 2014 22:50:12 +0000 Message-ID: <72381AF1F18BAE4F890A0813768D992817FCDDEC@sdcexchms.au.logicalis.com> References: <20140111004402.10451.90724.idtracker@ietfa.amsl.com> <72381AF1F18BAE4F890A0813768D992817FCA84E@sdcexchms.au.logicalis.com> <1390035508.23310.YahooMailNeo@web120503.mail.ne1.yahoo.com> In-Reply-To: <1390035508.23310.YahooMailNeo@web120503.mail.ne1.yahoo.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.196.183] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.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, 19 Jan 2014 22:50:32 -0000 SGkgTWFyaywgDQoNCldoZW4gd2Ugd2VyZSBsb29raW5nIGF0IGFjY2VsZXJhdGluZyBEQUQgZm9y IG1vYmlsZSBub2RlcyBhIHdoaWxlIGFnbywgSSBpbnZlc3RpZ2F0ZWQgdGhlIHN0YXRlIGhlbGQg YnkgTUxEIGFuZCB3cm90ZSBhIGRyYWZ0Lg0KKE5vdyBleHBpcmVkIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWRhbGV5LWlwdjYtbWNhc3QtZGFkLTAyKQ0KDQpBIG11Y2ggYmV0dGVy IHNvbHV0aW9uIHdhcyBmb3VuZCAobm93IFJGQyA0NDI5KSwgYnV0IHRoZSBjb25zaXN0ZW50IHN0 YXRlIGtlZXBpbmcgYnkgdGhlIE1MRCBxdWVyaWVyIChhbmQgb3RoZXIgcm91dGVycykgaXMgc3Rp bGwgcHJlc2VudCAocGFydGljdWxhcmx5IGZvciBNTER2MikuDQoNCihJIGFtIG5vdyB0aGlua2lu ZyBvdXQgbG91ZCwgc28gcGxlYXNlIGJlYXIgd2l0aCBtZSkNCg0KVGhlIGRpZmZlcmVuY2UgaXMg dGhhdCB0aGUgc29saWNpdGVkIG5vZGVzJyBhZGRyZXNzIHdhcyBub3QgaWRlbnRpY2FsIHRvIGFu IGFkZHJlc3MgYmluZGluZyBhbmQgdGhhdCAoYWZ0ZXIgbGlzdGVuZXIgc3RhdGUgc3luY2hyb25p emF0aW9uKSBvbmx5IHRoZSBub24tcHJlc2VuY2Ugb2YgYW4gTUxEIGxpc3RlbmVyIG9uIHRoZSBz b2xpY2l0ZWQgbm9kZXMgYWRkcmVzcyBjb3VsZCBiZSB1c2VkIHRvIHByb3ZlIHRoZSBhZGRyZXNz IHdhcyBhYnNlbnQuICBGb3IgcmVsYXRpdmVseSBzcGFyc2UgbGlua3MgYW5kIHN1Ym5ldHMgdGhp cyB3b3VsZCBhbGxvdyB0aGUgcm91dGVyIHRvIHN0YXRlIGV4cGxpY2l0bHkgdGhhdCB0aGUgYWRk cmVzcyB3YXMgbm90IGluIHVzZS4NCg0KRm9yIE5EIGNhY2hlIHByb3RlY3Rpb24sIHRoZSBwcmVz ZW5jZSBvZiBhbnkgTUxEIGxpc3RlbmVyIG9uIHRoZSBzb2xpY2l0ZWQgbm9kZXMnIGFjdGl2YXRl cyB0aGUgZ3JvdXAsIGFuZCBuby1saXN0ZW5lcnMgbWVhbnMgdGhlcmUgaXNuJ3QgZXZlbiBhIHJl YXNvbiB0byB0cmFuc21pdCB0aGUgbmVpZ2hib3VyIHNvbGljaXRhdGlvbi4NCg0KVW5sZXNzIHRo ZSByb3V0ZXIgbWFpbnRhaW5zIGFkZGl0aW9uYWwgTkQgY2FjaGUgc3RhdGUsIGl0IGNhbm5vdCBk aXN0aW5ndWlzaCBiZXR3ZWVuIGFuIGFjdGl2YXRlZCBncm91cCBhbmQgd2hpY2ggb2YgdGhlIGFk ZHJlc3NlcyBpcyBhY3RpdmUsIGFuZCB0aHVzIGEgc3Vic2V0IG9mIHRoZSBhZGRyZXNzZXMgKGUu Zy4gdGhlIGdsb2JhbGx5IHJvdXRhYmxlIGVxdWl2YWxlbnQgb2YgYSBMaW5rLWxvY2FsIGFkZHJl c3Mgd2l0aCBhIHBhcnRpY3VsYXIgc29saWNpdGVkIG5vZGVzIFthbmQgYW55dGhpbmcgd2l0aCB0 aGUgc2FtZSBJSUQgbG93ZXIgb3JkZXIgYml0c10pLg0KDQpJcyB0aGlzIHN1ZmZpY2llbnQgcHJv dGVjdGlvbiwgb3IgZG9lcyB0aGVyZSBoYXZlIHRvIGJlIG1vcmUgc3BlY2lmaWMgc3RhdGUgZ2F0 aGVyZWQgaW4gdGhlIE5EIGNhY2hlLCBwZXJoYXBzIHRocm91Z2ggdGhlIGRpc2N1c3NlZCBkcmFm dD8NCg0KU2luY2VyZWx5LCANCg0KR3JlZyBEYWxleQ0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IE1hcmsgWlpaIFNtaXRoIFttYWlsdG86bWFya3p6enNtaXRoQHlhaG9v LmNvbS5hdV0gDQpTZW50OiBTYXR1cmRheSwgMTggSmFudWFyeSAyMDE0IDc6NTggUE0NClRvOiBH cmVnIERhbGV5OyAnSW5nLVdoZXIgQ2hlbic7IGlwdjZAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhhbHBlcm4tNm1hbi1uZC1wcmUtcmVz b2x2ZS1hZGRyLTAwLnR4dA0KDQoNCg0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0N Cj4gRnJvbTogR3JlZyBEYWxleSA8Z2RhbGV5QGF1LmxvZ2ljYWxpcy5jb20+DQo+IFRvOiAnSW5n LVdoZXIgQ2hlbicgPGluZy13aGVyLmNoZW5AZXJpY3Nzb24uY29tPjsgImlwdjZAaWV0Zi5vcmci IA0KPiA8aXB2NkBpZXRmLm9yZz4NCj4gQ2M6IA0KPiBTZW50OiBGcmlkYXksIDE3IEphbnVhcnkg MjAxNCAxOjE0IFBNDQo+IFN1YmplY3Q6IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IA0KPiBkcmFmdC1oYWxwZXJuLTZtYW4tbmQtcHJlLXJlc29sdmUtYWRkci0wMC50eHQNCj4gDQo+ IEhpIEhlbGVuLA0KPiANCjxzbmlwPg0KDQo+IA0KPiAzLyBNb25pdG9yIHRoZSBzb2xpY2l0ZWQg bm9kZXMnIGFkZHJlc3NlcyBpbiB0aGUgTUxEIHF1ZXJpZXIgcm91dGVyLCANCj4gYW5kIGRvIG5v dCB0cmFuc21pdCBhbiBOUyBmcm9tIG9mZi1saW5rIGZvciBhbiBpbmNvbXBsZXRlIGFkZHJlc3Mg DQo+IHVubGVzcyBzb21lb25lIGlzIGxpc3RlbmluZy4NCj4NCg0KU28gSSd2ZSBiZWVuIHRoaW5r aW5nIGZvciB0aGUgbGFzdCBmZXcgbW9udGhzIHRoYXQgdGhpcyBtZXRob2QgY291bGQgYmUgYSB1 c2VmdWwgZnVydGhlciBtaXRpZ2F0aW9uIHRvIG9mZi1saW5rIE5EIGNhY2hlIGF0dGFja3MgZm9y IHJvdXRlcnMuIEkndmUgYmVlbiB3cml0aW5nIHNvbWV0aGluZyB1cCB3aGljaCBJJ3ZlIGJlZW4g cGxhbm5pbmcgdG8gZmluaXNoIGFuZCBwb3N0IGluIHRoZSBuZXh0IHdlZWsgb3Igc28uDQoNCkkg dGhpbmsgaXQgY291bGQgYmUgZmFpcmx5IGVmZmVjdGl2ZSAtIHRoZXJlIGFyZSBhIHRvdGFsIHBv c3NpYmxlIDJeMjQgc29saWNpdGVkLW5vZGUgbXVsdGljYXN0IGdyb3VwcyBvbiBhIGxpbmssIHdo ZXJlIGFzIHRoZXJlIHdpbGwgb25seSBiZSBhcyBtYW55IHByZXNlbnQgb25lcyBhcyB0aGVyZSBh cmUgSUlEcyB3aXRoIHVuaXF1ZSBsb3dlciAyNCBiaXRzLiBGb3IgbW9zdCBzdWJuZXRzIEkgdGhp bmsgdGhhdCB3aWxsIG51bWJlciBpbiB0aGUgb3JkZXIgb2YgMTBzIG9yIDEwMHMsIGFuZCBwZXJo YXBzIG9uIHJhcmUgb2NjYXNpb25zIGluIHRoZSBsb3cgMTAwMHMuIFNvIE5TZXMgd291bGQgb25s eSBiZSBuZWNlc3NhcnkgZm9yIGUuZy4gMTAwMC8yXjI0IHBvcnRpb24gb2YgdGhlIHVuaWNhc3Qg YWRkcmVzcyBzcGFjZSwgb3RoZXJ3aXNlIHRoZSBwYWNrZXRzIHRoYXQgd291bGQgdHJpZ2dlciB0 aGVtIGNhbiBiZSBkcm9wcGVkIChvciBwZXJoYXBzIHNlbnQgdG8gYW4gUkZDNjAxOCBncmV5bmV0 IGNvbGxlY3RvcikuDQoNCkEgbmVpZ2hib3IgY2FjaGUgYXR0YWNrIGlzIGxpa2VseSB0byBiZSBz dGlsbCBiZSBwb3NzaWJsZSBmb3IgdGhlIDJeNDAgcG9ydGlvbnMgb2YgdW5pY2FzdCBhZGRyZXNz IHNwYWNlIGNvdmVyZWQgYnkgZWFjaCBvZiB0aGUgdGhlIHByZXNlbnQgc29saWNpdGVkLW11bHRp Y2FzdCBncm91cHMsIGhvd2V2ZXIgRmVybmFuZG8ncyBTdGFibGUvT3BhcXVlIElJRCBkcmFmdCB3 b3VsZCBtYWtlIHRoZW0gaGFyZGVyIHRvIGZpbmQsIGV2ZW4gdGhvdWdoIGl0IHdpbGwgaW5jcmVh c2UgdGhlIG51bWJlciBvZiB0aGVtLCBhcyB0aGVyZSBpcyBhbiB1bmlxdWUgT3BhcXVlIElJRCBw ZXIgcHJlZml4Lg0KDQpBbGwgcm91dGVycyBsaXN0ZW5pbmcgdG8gTUxEIHRyYWNrIGdyb3VwIG1l bWJlcnNoaXAsIG5vdCBqdXN0IHRoZSBNTEQgcXVlcmllciwgc28gYWxsIHJvdXRlcnMgb24gdGhl IGxpbmsgY291bGQgaW1wbGVtZW50IHRoaXMgbWV0aG9kLg0KDQpSZWdhcmRzLA0KTWFyay4NCg== From mls.ietf@gmail.com Mon Jan 20 02:10: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 A13FF1A00D6; Mon, 20 Jan 2014 02:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.301 X-Spam-Level: ** X-Spam-Status: No, score=2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, MANGLED_OFF=2.3] 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 30i__GH6znll; Mon, 20 Jan 2014 02:10:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA331A00C5; Mon, 20 Jan 2014 02:10:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Martin Stiemerling" To: The IESG Subject: Martin Stiemerling's 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: <20140120101020.1584.34146.idtracker@ietfa.amsl.com> Date: Mon, 20 Jan 2014 02:10:20 -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: Mon, 20 Jan 2014 10:10:21 -0000 Martin Stiemerling 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: ---------------------------------------------------------------------- Section 2., paragraph 4: > Note that the result of F() in the algorithm above is no more secure > than the secret key. If an attacker is aware of the PRF that is > being used by the victim (which we should expect), and the attacker > can obtain enough material (i.e. addresses configured by the victim), > the attacker may simply search the entire secret-key space to find > matches. To protect against this, the secret key should be of a > reasonable length. Key lengths of at least 128 bits should be > adequate. The secret key is initialized at system installation time > to a pseudo-random number, thus allowing this mechanism to be enabled > /used automatically, without user intervention. Isn't there a requirement (MUST) or at least a recommendation (RECOMMENDED) to say something about the minimum length of the secret key? Just to let implementers know from what length on the secret is 'safe' as input? From fernando@gont.com.ar Mon Jan 20 02:43: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 09E731A00FC; Mon, 20 Jan 2014 02:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.098 X-Spam-Level: *** X-Spam-Status: No, score=3.098 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_OFF=2.3, 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 L4FhSwCXepv5; Mon, 20 Jan 2014 02:43:28 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7D61A00FA; Mon, 20 Jan 2014 02:43:27 -0800 (PST) Received: from 6-154-16-190.fibertel.com.ar ([190.16.154.6] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W5CKB-0005dY-4x; Mon, 20 Jan 2014 11:43:23 +0100 Message-ID: <52DCFDC1.3080100@gont.com.ar> Date: Mon, 20 Jan 2014 07:43:13 -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: Martin Stiemerling , The IESG Subject: Re: Martin Stiemerling's No Objection on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT) References: <20140120101020.1584.34146.idtracker@ietfa.amsl.com> In-Reply-To: <20140120101020.1584.34146.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Mon, 20 Jan 2014 10:43:30 -0000 Hi, Martin, Thanks so much for your review! Please find my comments in-line... On 01/20/2014 07:10 AM, Martin Stiemerling wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 2., paragraph 4: > >> Note that the result of F() in the algorithm above is no more > secure >> than the secret key. If an attacker is aware of the PRF that is >> being used by the victim (which we should expect), and the attacker >> can obtain enough material (i.e. addresses configured by the > victim), >> the attacker may simply search the entire secret-key space to find >> matches. To protect against this, the secret key should be of a >> reasonable length. Key lengths of at least 128 bits should be >> adequate. The secret key is initialized at system installation > time >> to a pseudo-random number, thus allowing this mechanism to be > enabled >> /used automatically, without user intervention. > > Isn't there a requirement (MUST) or at least a recommendation > (RECOMMENDED) to say something about the minimum length of the secret > key? Just to let implementers know from what length on the secret is > 'safe' as input? I think we could change: "To protect against this, the secret key should be of a reasonable length. Key lengths of at least 128 bits should be adequate." to: "To protect against this, the secret key SHOULD be of at least 128 bits." However, this is intertwined with the choice of F(), which we're not specifying (since it represents a tradeoff). So, while I see your point, I'm not sure whether that would make sense. Thoughts? 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 mls.ietf@gmail.com Mon Jan 20 06:36: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 54EBE1A0175; Mon, 20 Jan 2014 06:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 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, MANGLED_OFF=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 uDHdsWCWz3IF; Mon, 20 Jan 2014 06:36:56 -0800 (PST) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id A2DBC1A015B; Mon, 20 Jan 2014 06:36:55 -0800 (PST) Received: by mail-ee0-f41.google.com with SMTP id e49so3524286eek.0 for ; Mon, 20 Jan 2014 06:36:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=fjSEBRWr9Rxmi11mw4WOHqQ1gx8iyk8mjLuCV17GxiY=; b=IZ/XIfKSMpbmcOVtk28DT09PHGCjLbuESeyAuF2Nw8l6h0/jKOiBWvTb/vhbjzx1t2 TzrC+59/Hs4r+5wZIxPyMq+VdDTWsbHyAMFJTIqLNmaWTPLCP7s2nyOCoHNMD1WxGLdO jiXWkUdfDv0JADtQUlNYjz+4g3KolW6sdJazMgp43950AGdq5o6JQB9Qvy06BKvpmtVk OMEzW92bd2RutTgl60ZX8chmU+YWsCpz/nsN5SomdxTrG0E0Rea0dpzoEkoSwGV8FGkA ezcvqLlABLY09K9M74i4N0LV/SB2YH+3YwTtAWmv1k1F3r2doQKUR+0x9aIIR06o0pEj JSqQ== X-Received: by 10.14.178.65 with SMTP id e41mr2629044eem.79.1390228615425; Mon, 20 Jan 2014 06:36:55 -0800 (PST) Received: from [10.1.1.137] (mito.netlab.nec.de. [195.37.70.39]) by mx.google.com with ESMTPSA id l4sm3765520een.13.2014.01.20.06.36.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Jan 2014 06:36:54 -0800 (PST) Message-ID: <52DD3485.1040107@gmail.com> Date: Mon, 20 Jan 2014 15:36:53 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Fernando Gont , The IESG Subject: Re: Martin Stiemerling's No Objection on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT) References: <20140120101020.1584.34146.idtracker@ietfa.amsl.com> <52DCFDC1.3080100@gont.com.ar> In-Reply-To: <52DCFDC1.3080100@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Mon, 20 Jan 2014 14:36:57 -0000 Hi Fernando, On 01/20/2014 11:43 AM, Fernando Gont wrote: > Hi, Martin, > > Thanks so much for your review! Please find my comments in-line... > > > On 01/20/2014 07:10 AM, Martin Stiemerling wrote: >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Section 2., paragraph 4: >> >>> Note that the result of F() in the algorithm above is no more >> secure >>> than the secret key. If an attacker is aware of the PRF that is >>> being used by the victim (which we should expect), and the attacker >>> can obtain enough material (i.e. addresses configured by the >> victim), >>> the attacker may simply search the entire secret-key space to find >>> matches. To protect against this, the secret key should be of a >>> reasonable length. Key lengths of at least 128 bits should be >>> adequate. The secret key is initialized at system installation >> time >>> to a pseudo-random number, thus allowing this mechanism to be >> enabled >>> /used automatically, without user intervention. >> >> Isn't there a requirement (MUST) or at least a recommendation >> (RECOMMENDED) to say something about the minimum length of the secret >> key? Just to let implementers know from what length on the secret is >> 'safe' as input? > > I think we could change: > > "To protect against this, the secret key should be of a > reasonable length. Key lengths of at least 128 bits should be > adequate." > > to: > > "To protect against this, the secret key SHOULD be of at least > 128 bits." > > > However, this is intertwined with the choice of F(), which we're not > specifying (since it represents a tradeoff). So, while I see your point, > I'm not sure whether that would make sense. I'm also torn, but I would add a minimum recommendation, so that implementers have a lower limit to start from. Your text proposal is good and better than 'reasonable length'. Thanks, Martin > > Thoughts? > > Thanks! > > Best regards, > From ietf@rozanak.com Mon Jan 20 10:21: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 915D31A0222 for ; Mon, 20 Jan 2014 10:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.265 X-Spam-Level: X-Spam-Status: No, score=0.265 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 8OsdwNZxkFl2 for ; Mon, 20 Jan 2014 10:21:20 -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 00C851A01E5 for ; Mon, 20 Jan 2014 10:21:19 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id C112E23E2D48; Mon, 20 Jan 2014 18:21:18 +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 37dFsgdTnwQO; Mon, 20 Jan 2014 19:21:13 +0100 (CET) Received: from kopoli (g231195012.adsl.alicedsl.de [92.231.195.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 65D2923E2B25; Mon, 20 Jan 2014 19:21:12 +0100 (CET) From: "Hosnieh Rafiee" To: "'Fernando Gont'" , "'Fernando Gont'" , "'Ole Troan'" , "'6man WG'" Subject: RE: On SEND deployment (Re: Conclusion: 6MAN Adoption call on draft-rafiee-6man-ssas-07) Date: Mon, 20 Jan 2014 19:21:11 +0100 Message-ID: <001501cf160c$66105a00$32310e00$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8WDGN4/fj2matnTPmt+IaYi/jFTw== Content-Language: en-us 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: Mon, 20 Jan 2014 18:21:22 -0000 Fernando, Just a quick review about SSAS to give you and those who didn't get the idea of SSAS a short review. If you review the SSAS draft, you will find out that you can either use it as an option of SeND or use it alone. So, it doesn't necessarily need to deploy with SeND but if one wants to use it as a SeND option, it is also possible but in this case it doesn't need to carry the signature in SSAS data structure. I explained this all in version 8 of this draft and addressed all the issues. About why SeND is not deployed again, I refer you to the local security draft that I wrote which is informational draft. You can find some of the reasons that I gathered during the discussions with people. http://tools.ietf.org/html/draft-rafiee-6man-local-security-00#section-4.1 Some notes, None of the existing approaches can prevent IP spoofing, with some of the approaches you can mitigate fake RA spoofing but not host IP address spoofing. > > Hosnieh, > > On 01/17/2014 02:52 AM, Hosnieh Rafiee wrote: > >> My two cents: > >> > >> * Use of trust anchors makes deployment painful for the general case. > > > > This is why I proposed a local centralized RPKI in the second draft. > > What do you mean by "local centralized"? Whether the PKI is local or global > doesn't seem to affect how hard this is to deploy. > > > > >> * Most popular OSes do not have a real SEND implementation (not long > >> ago the only way to play on BSDs was a Java implementation?). When it > >> comes to open source ones, the fact that SEND is IPR'ed doesn't help the > situation. > > > > The reason is because of CGA > > IIRC, there were *two* patents on SEND. > > > > >> * While other parts of the "system" are largely unsecured, SeND > >> probably does not much. (e.g, if a local attacker can spoof a DNS > >> response, > > securing the > >> layer-2/3 mapping will not buy much in most cases -- i.e., just spoof > >> the > > DNS > >> response, and you're done). > > > > I considered DNS spoofing to address that problem by proposing > > CGA-TSIG (it use both SSAS/CGA as its solution) and it is implemented. > > I didn't go through your I-D in detail, hence I cannot comment one way or > another. > > Based on the discussions it seems folks are not convinced why this would be > easier to deploy than send. So if you're willing to continue pursuing this effort, > you could try to spell out the reasons for which SEND has not been widely > deployed, and provide a clear explanation on why your proposal would make > a difference. -- Feel free to start from the reasons I provided, or tweak as > deemed necessary. You can actually find the reasons inside the drafts and all supportive drafts. At least in version 8 I tried to clarify the reasons. > > >> * SEND wasn't there for v4. And there's a tendency to try to employ > >> IPv6 as IPv4, focusing on the benefit of the larger address space > >> (i.e., > > for > >> some, "I lived with this in v4 for 20+ years, so..."). Not that I > > necessarily > >> endorse this view, but just meant to spell it out. > > > > Current available mechanism also have problem and cannot mitigate IP > > spoofing. This is the main reason I wrote that local security draft to > > address these problems. > > Agreed. But we're analyzing why SEND has not been widely deployed. If folks > out there do not consider this is to be a problem that is worth addressing, no > matter what solution we propose, it will still be a "problem not worth > addressing" from their point of view. Why do you think that I established a non-WG group. I want really to solve the problem of local security and deploy it and also use it as a means of authentication for other layers. I again refer you to that local security draft. I really tried to discuss the problem and inform the possible solutions. Hosnieh From swmike@swm.pp.se Mon Jan 20 11:24: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 A80811A0239 for ; Mon, 20 Jan 2014 11:24:42 -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_SE=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 kcawz6H50CLl for ; Mon, 20 Jan 2014 11:24:40 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5BC1A01DC for ; Mon, 20 Jan 2014 11:24:40 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 08ED09C; Mon, 20 Jan 2014 20:24:39 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 009129A; Mon, 20 Jan 2014 20:24:38 +0100 (CET) Date: Mon, 20 Jan 2014 20:24:38 +0100 (CET) From: Mikael Abrahamsson To: Hosnieh Rafiee Subject: RE: On SEND deployment (Re: Conclusion: 6MAN Adoption call on draft-rafiee-6man-ssas-07) In-Reply-To: <001501cf160c$66105a00$32310e00$@rozanak.com> Message-ID: References: <001501cf160c$66105a00$32310e00$@rozanak.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: '6man Chairs' <6man-chairs@tools.ietf.org>, 'Fernando Gont' , '6man WG' , '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, 20 Jan 2014 19:24:42 -0000 On Mon, 20 Jan 2014, Hosnieh Rafiee wrote: > About why SeND is not deployed again, I refer you to the local security > draft that I wrote which is informational draft. You can find some of > the reasons that I gathered during the discussions with people. > http://tools.ietf.org/html/draft-rafiee-6man-local-security-00#section-4.1 > > Some notes, > > None of the existing approaches can prevent IP spoofing, with some of the > approaches you can mitigate fake RA spoofing but not host IP address > spoofing. SAVI WG works with these issues. I would really like to see some of their work referenced in your draft. http://tools.ietf.org/wg/savi/ -- Mikael Abrahamsson email: swmike@swm.pp.se From ing-wher.chen@ericsson.com Mon Jan 20 16:09: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 E69611A027B for ; Mon, 20 Jan 2014 16:09:58 -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 7Pl4HnDjilPB for ; Mon, 20 Jan 2014 16:09:57 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id EB0A01A027D for ; Mon, 20 Jan 2014 16:09:56 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-60-52ddbad1d11d Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id BD.D7.23183.1DABDD25; Tue, 21 Jan 2014 01:09:54 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0387.000; Mon, 20 Jan 2014 19:09:56 -0500 From: Ing-Wher Chen To: "ipv6@ietf.org" Subject: Re: draft-halpern-6man-nd-pre-resolve-addr-00.txt Thread-Topic: Re: draft-halpern-6man-nd-pre-resolve-addr-00.txt Thread-Index: Ac8WO612+5i6/7LGRdax1VWN2uymEw== Date: Tue, 21 Jan 2014 00:09:56 +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.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrALMWRmVeSWpSXmKPExsUyuXRPuO6lXXeDDPo/MVm8PPueyYHRY8mS n0wBjFFcNimpOZllqUX6dglcGa8mvWErmC1S8W1qL1MD4xyBLkZODgkBE4kDu16zQdhiEhfu rQeyuTiEBI4wSrxsfgTlLGeUePpnKjNIFZuAgcSGj1uYQGwRAWWJGd3nwLqFBawlWvd/YYWI O0i8ObyQBcLWk5j58BdYnEVAFWjDCrA4r4C3REd7IyOIzQi0+fupNWAzmQXEJW49mc8EcZGA xJI955khbFGJl4//sULYihL7+qezQ9TrSCzY/YkNwtaWWLbwNTPEfEGJkzOfsExgFJ6FZOws JC2zkLTMQtKygJFlFSNHaXFqWW66kcEmRmAoH5Ng093BuOel5SFGaQ4WJXHeL2+dg4QE0hNL UrNTUwtSi+KLSnNSiw8xMnFwSjUwrl1hdlPkIP+67DdOBZLuH9jXFEy9UF+cr8nT+iNNQPvs f+P5OQJFpQf/HGfqixZfeMMxw56F8eZ1kyeXjF7bLku4yuo/Memnr8MjFa3LSbYxp1av1vMP Fj2n3StTFtrSYrY9df2Txckdm+Zz15169CFSJbP5LlPW1EeqR3YuNz506XWZntItJZbijERD Leai4kQA/e87ETMCAAA= 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 00:09:59 -0000 > -----Original Message----- > From: Erik Nordmark [mailto:nordmark@acm.org] > Sent: Friday, January 17, 2014 9:02 PM > To: Greg Daley; Ing-Wher Chen; ipv6@ietf.org > Subject: Re: New Version Notification for draft-halpern-6man-nd-pre-=20 > resolve-addr-00.txt > ... > In addition to your concern about multicast snooping environments, the=20 > DAD packets are not reliably delivered. If e.g. there is a short WiFi=20 > drop, the spanning tree is reconverging, etc then the single=20 > transmitted DAD packet will not be received. No ND packets are reliably delivered. So this is not different from any ot= her ND traffic. > Thus as best this will collect some entries in the neighbor cache. We agree that the approach in the draft might not capture all neighbors. However, when a router is under an off-link attack, having this additional source of target addresses will mean that the router can continue to servic= e new hosts, as it sees them. The alternative, without the approach in the d= raft, is that the router does not service any additional new hosts, starting from the time the router is under attack. (The DAD-NS approach can be seen as a heuristic to distinguish legitimate target addresses from invalid target ad= dresses.) =20 In short, using the approach in the draft will yield a better result than n= ot using it. Since DOS attacks are impossible to prevent in the general case, all that c= an be done -- by any mechanism -- is to reduce the impact of such attacks. This = approach does reduce the impact of such attacks. > It isn't at all clear when a node should discard entries from its=20 > neighbor cache. That is potentially problematic when there are lots of=20 > devices that pick new temporary IPv6 addresses each time they power on=20 > since that will force routers to sooner or later discard entries from=20 > the neighbor cache. The routers would have to guess which addresses=20 > might still be assigned to the hosts. We rely on Neighbor Unreachability Detection to remove stale neighbors, as = specified by the existing IETF ND standards. We believe the standards make this clea= r. We are happy to cite the existing ND standards in this area (NUD to remove stale n= eighbors) more explicitly in a future version of this draft. > Thus all in all this is not a robust approach to the problem. There is no perfect solution to a DOS attack. This method yields better re= sults than not using this method, reducing the severity of the attack in a measurable = way. Thanks, Helen From nordmark@acm.org Mon Jan 20 17:57: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 880AD1A025B for ; Mon, 20 Jan 2014 17:57:59 -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 6ic6w1ByOpBU for ; Mon, 20 Jan 2014 17:57: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 E1B711A0002 for ; Mon, 20 Jan 2014 17:57:57 -0800 (PST) Received: from [10.0.0.134] (75-94-138-38.sfo.clearwire-wmx.net [75.94.138.38] (may be forged)) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s0L1vnIs002564 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 20 Jan 2014 17:57:51 -0800 Message-ID: <52DDD41C.4000905@acm.org> Date: Mon, 20 Jan 2014 17:57:48 -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: Ing-Wher Chen , "ipv6@ietf.org" Subject: Re: draft-halpern-6man-nd-pre-resolve-addr-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;Ki+Cbj+C4xGyEDqjisUCUQ== M;gOg6bz+C4xGyEDqjisUCUQ== 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 01:57:59 -0000 On 1/20/14 4:09 PM, Ing-Wher Chen wrote: > >> -----Original Message----- >> From: Erik Nordmark [mailto:nordmark@acm.org] >> Sent: Friday, January 17, 2014 9:02 PM >> To: Greg Daley; Ing-Wher Chen; ipv6@ietf.org >> Subject: Re: New Version Notification for draft-halpern-6man-nd-pre- >> resolve-addr-00.txt >> ... >> In addition to your concern about multicast snooping environments, the >> DAD packets are not reliably delivered. If e.g. there is a short WiFi >> drop, the spanning tree is reconverging, etc then the single >> transmitted DAD packet will not be received. > > No ND packets are reliably delivered. So this is not different from any other ND traffic. The DAD probe is different that NS messages used for address resolution. For address resolution the NS is retransmitted (3 times) until there is a response. But the DAD probe is single (multicast) NS message, and if there is no response in one second then the node will conclude that there is no duplicate. Thus if there is packet loss (e.g., on WiFi where multicast packets don't get ARQ), or on wired Ethernet with a spanning tree reconvergence when the DAD probe is sent, then the prober will incorrectly assume it is not a duplicate. RFC 4862 talks about this lack of guarantees in section 5.4. >> Thus as best this will collect some entries in the neighbor cache. > > We agree that the approach in the draft might not capture all neighbors. > However, when a router is under an off-link attack, having this additional > source of target addresses will mean that the router can continue to service > new hosts, as it sees them. The alternative, without the approach in the draft, > is that the router does not service any additional new hosts, starting from > the time the router is under attack. (The DAD-NS approach can be seen as a > heuristic to distinguish legitimate target addresses from invalid target addresses.) I don't think you need to do anything special with DAD to accomplish that. When a new host appears it will send other packets to the router (the first might be either a RS or a NS depending on the host implementation) which includes a source IPv6 address and a source link-layer address. The router would (according to RFC 4861) populate the neighbor cache based on the source information that RS or NS. What does overloading the DAD probe do in addition? > In short, using the approach in the draft will yield a better result than not using it. Please provide more information. Do you have studies of existing implementations that show that they do not populate the neighbor cache based on the source of the RS or NS? Is that an implementation issue or a standards issue? > Since DOS attacks are impossible to prevent in the general case, all that can be > done -- by any mechanism -- is to reduce the impact of such attacks. This approach > does reduce the impact of such attacks. In don't see how it reduces the impact assuming the host and router follows RFC 4861. >> It isn't at all clear when a node should discard entries from its >> neighbor cache. That is potentially problematic when there are lots of >> devices that pick new temporary IPv6 addresses each time they power on >> since that will force routers to sooner or later discard entries from >> the neighbor cache. The routers would have to guess which addresses >> might still be assigned to the hosts. > > We rely on Neighbor Unreachability Detection to remove stale neighbors, as specified > by the existing IETF ND standards. We believe the standards make this clear. We are > happy to cite the existing ND standards in this area (NUD to remove stale neighbors) > more explicitly in a future version of this draft. But NUD only comes into play if there is traffic towards those IP addresses. An implementation needs a strategy to garbage collect NCEs in the absence of traffic that would trigger NUD. Erik >> Thus all in all this is not a robust approach to the problem. > > There is no perfect solution to a DOS attack. This method yields better results than > not using this method, reducing the severity of the attack in a measurable way. > > Thanks, > Helen > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From stbryant@cisco.com Tue Jan 21 04:47: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 8B4531A00D1; Tue, 21 Jan 2014 04:47:20 -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 wrWjIofE-Flg; Tue, 21 Jan 2014 04:47:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CB51A00C9; Tue, 21 Jan 2014 04:47:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Stewart Bryant" To: The IESG Subject: Stewart Bryant's 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: <20140121124718.28900.56916.idtracker@ietfa.amsl.com> Date: Tue, 21 Jan 2014 04:47:18 -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: Tue, 21 Jan 2014 12:47:20 -0000 Stewart Bryant 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: ---------------------------------------------------------------------- As Adrian says, this does not look like it impacts the routing systems so based on a quick skim, no objection. I am, however, left pondering as to whether a simple call to the system RNG wouldn't work well enough most of the time. From stephen.farrell@cs.tcd.ie Tue Jan 21 07:52: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 8CD931A0369; Tue, 21 Jan 2014 07:52: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 AG15AcFoZZ6R; Tue, 21 Jan 2014 07:52:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86EDA1A0368; Tue, 21 Jan 2014 07:52:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Stephen Farrell" To: The IESG Subject: Stephen Farrell's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS and COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140121155253.23475.70004.idtracker@ietfa.amsl.com> Date: Tue, 21 Jan 2014 07:52:53 -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: Tue, 21 Jan 2014 15:52:55 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-6man-stable-privacy-addresses-16: Discuss 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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) Section 5: Why mention only MD5 and SHA1? Why not HMAC-SHA256? 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. 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. = (*) 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. (2) Why might a sys admin want to display the secret key? 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. ---------------------------------------------------------------------- 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. 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. From fernando@gont.com.ar Tue Jan 21 08:01: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 BE51E1A03F0; Tue, 21 Jan 2014 08:01: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 UM2MiXN7R2KW; Tue, 21 Jan 2014 08:01:00 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id E17541A017E; Tue, 21 Jan 2014 08:00:55 -0800 (PST) Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W5dkz-00076G-1x; Tue, 21 Jan 2014 17:00:53 +0100 Message-ID: <52DE9158.3080307@gont.com.ar> Date: Tue, 21 Jan 2014 12:25:12 -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: Stewart Bryant , The IESG Subject: Re: Stewart Bryant's No Objection on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT) References: <20140121124718.28900.56916.idtracker@ietfa.amsl.com> In-Reply-To: <20140121124718.28900.56916.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 16:01:02 -0000 Hi, Stewart, Thanks so much for you input! Please find my comments in-line... On 01/21/2014 09:47 AM, Stewart Bryant wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > As Adrian says, this does not look like it impacts the routing systems so > based on a quick skim, no objection. > > I am, however, left pondering as to whether a simple call to the system > RNG wouldn't work well enough most of the time. Because the resulting addresses wouldn't be stable. And if they are not stable, things like ACLs and anything that benefits from stable addresses wouldn't work as expected (that's why e.g. many folks disable RFC 4941) 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 fgont@si6networks.com Tue Jan 21 08:37: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 75BB11A037C; Tue, 21 Jan 2014 08:37:20 -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 jKd4L6gjWn5F; Tue, 21 Jan 2014 08:37:19 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id D3D7D1A0386; Tue, 21 Jan 2014 08:37:18 -0800 (PST) Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W5eK7-0007xy-0F; Tue, 21 Jan 2014 17:37:12 +0100 Message-ID: <52DE9E63.5050404@si6networks.com> Date: Tue, 21 Jan 2014 13:20:51 -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: 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> In-Reply-To: <20140121155253.23475.70004.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 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: Tue, 21 Jan 2014 16:37:20 -0000 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 simon.perreault@viagenie.ca Tue Jan 21 08:47: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 1787B1A0191; Tue, 21 Jan 2014 08:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 MHexzJAQjiMG; Tue, 21 Jan 2014 08:47:19 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 40D851A00C8; Tue, 21 Jan 2014 08:47:19 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C7F8F40367; Tue, 21 Jan 2014 11:47:18 -0500 (EST) Message-ID: <52DEA496.9000000@viagenie.ca> Date: Tue, 21 Jan 2014 11:47:18 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: 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> In-Reply-To: <52DE9E63.5050404@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: Tue, 21 Jan 2014 16:47:21 -0000 It said "DISCUSS" at the top, so I'll do just that... Le 2014-01-21 11:20, Fernando Gont a écrit : > 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. 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. >> (2) Why might a sys admin want to display the >> secret key? > > e.g., you want a replacement system to generate the same addresses. Good reason IMHO. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From hannes@stressinduktion.org Tue Jan 21 08:51: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 D812D1A0119; Tue, 21 Jan 2014 08:51:34 -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, 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 ddWVc4_1Z0ZZ; Tue, 21 Jan 2014 08:51:32 -0800 (PST) Received: from order.stressinduktion.org (order.stressinduktion.org [87.106.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id 72B3B1A0173; Tue, 21 Jan 2014 08:51:30 -0800 (PST) Received: by order.stressinduktion.org (Postfix, from userid 500) id 9DCDC1A0C277; Tue, 21 Jan 2014 17:51:29 +0100 (CET) Date: Tue, 21 Jan 2014 17:51:29 +0100 From: Hannes Frederic Sowa To: Simon Perreault Subject: Re: Stephen Farrell's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS and COMMENT) Message-ID: <20140121165129.GI27626@order.stressinduktion.org> References: <20140121155253.23475.70004.idtracker@ietfa.amsl.com> <52DE9E63.5050404@si6networks.com> <52DEA496.9000000@viagenie.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <52DEA496.9000000@viagenie.ca> Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, Lloyd Wood , The IESG , draft-ietf-6man-stable-privacy-addresses@tools.ietf.org, Fernando Gont , Stephen Farrell 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 16:51:35 -0000 On Tue, Jan 21, 2014 at 11:47:18AM -0500, Simon Perreault wrote: > It said "DISCUSS" at the top, so I'll do just that... > > Le 2014-01-21 11:20, Fernando Gont a écrit : > >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. > > 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. As soon as we implement that in the kernel, we can use SHA-1 and MD-5, all other algorithms have a dependency on the crypto-api or must be restructured. Btw. for my linux PoC I used SHA-1: http://patchwork.ozlabs.org/patch/300938/ (maybe the comments there could be helpful as well). Greetings, Hannes From fgont@si6networks.com Tue Jan 21 09:35: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 612A81A01D4; Tue, 21 Jan 2014 09:35:24 -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 NxK9Cc7flNLg; Tue, 21 Jan 2014 09:35:22 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 851DC1A0187; Tue, 21 Jan 2014 09:35:22 -0800 (PST) Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W5fEK-0000wj-Q5; Tue, 21 Jan 2014 18:35:17 +0100 Message-ID: <52DEADE8.5060504@si6networks.com> Date: Tue, 21 Jan 2014 14:27: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: Simon Perreault , 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.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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: Tue, 21 Jan 2014 17:35:24 -0000 Hi, Simon, Thanks so much for your comments! -- Please find my reponses in-line... On 01/21/2014 01:47 PM, Simon Perreault wrote: > It said "DISCUSS" at the top, so I'll do just that... > > Le 2014-01-21 11:20, Fernando Gont a écrit : >> 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. > > 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. Stephen: Would juust removing MD5 address your DISCUSS? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Tue Jan 21 10:06: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 649C61A0180; Tue, 21 Jan 2014 10:06:29 -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 Gopa-5ovGDFk; Tue, 21 Jan 2014 10:06:27 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id BCCCF1A011D; Tue, 21 Jan 2014 10:06:27 -0800 (PST) Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W5fiQ-0001iD-Hv; Tue, 21 Jan 2014 19:06:22 +0100 Message-ID: <52DEB703.209@si6networks.com> Date: Tue, 21 Jan 2014 15:05: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: l.wood@surrey.ac.uk, 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) 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> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 18:06:29 -0000 On 01/21/2014 02:40 PM, l.wood@surrey.ac.uk wrote: > See (and cite) RFC6151 section 2. > > MD5 is still useful as a checksum for really big files, where you're > looking 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 properties, don't use MD5. Thanks Lloyd. :-) So it seems clear that MD5 should be removed as an example. Now the question seems to be whether should actually ditch MD5.... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From stephen.farrell@cs.tcd.ie Tue Jan 21 10:12: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 DB2961A011D; Tue, 21 Jan 2014 10:12:07 -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, 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 nSzxwfwo69KF; Tue, 21 Jan 2014 10:12:04 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0725A1A00C8; Tue, 21 Jan 2014 10:12:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3F8F3BE2F; Tue, 21 Jan 2014 18:12:03 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHtusXzW8mtF; Tue, 21 Jan 2014 18:12:03 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E17DFBE1C; Tue, 21 Jan 2014 18:12:02 +0000 (GMT) Message-ID: <52DEB873.1080500@cs.tcd.ie> Date: Tue, 21 Jan 2014 18:12:03 +0000 From: Stephen Farrell 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 , 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 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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: Tue, 21 Jan 2014 18:12:08 -0000 On 01/21/2014 04:47 PM, Simon Perreault wrote: > It said "DISCUSS" at the top, so I'll do just that... > > Le 2014-01-21 11:20, Fernando Gont a écrit : >> 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. > > 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. Right - give good examples and don't give bad ones is the easy fix. HMAC-SHA1 and HMAC-SHA256 would be good ones to give. (And if you have sha1 then you can easily use HMAC-SHA1.) >>> (2) Why might a sys admin want to display the >>> secret key? >> >> e.g., you want a replacement system to generate the same addresses. > > Good reason IMHO. Was that mentioned in the requirements? Seems a little less likely but I guess it could be one. 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' doesn't give me a nice warm security fuzzy feeling:-) and needs to be protected. Another easy fix if needed. (Apologies if that's there already and I missed it.) S. > > Simon From fgont@si6networks.com Tue Jan 21 11:13: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 943761A022A; Tue, 21 Jan 2014 11:13: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 E19-jUI0mvlw; Tue, 21 Jan 2014 11:13:28 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBDF1A021F; Tue, 21 Jan 2014 11:13:28 -0800 (PST) Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W5glF-0003Gx-IU; Tue, 21 Jan 2014 20:13:21 +0100 Message-ID: <52DEC5C8.7080903@si6networks.com> Date: Tue, 21 Jan 2014 16:08:56 -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: Stephen Farrell , Simon Perreault , 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> <52DEB873.1080500@cs.tcd.ie> In-Reply-To: <52DEB873.1080500@cs.tcd.ie> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 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: Tue, 21 Jan 2014 19:13:30 -0000 On 01/21/2014 03:12 PM, Stephen Farrell wrote: >>> They are just examples. I guess we could add HMAC-SHA256, too. I have no >>> objections to that. >> >> 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. > > Right - give good examples and don't give bad ones is the > easy fix. HMAC-SHA1 and HMAC-SHA256 would be good ones to > give. (And if you have sha1 then you can easily use HMAC-SHA1.) Ok. If you know of the URLs for the proper references, please do let me know. >>>> (2) Why might a sys admin want to display the >>>> secret key? >>> >>> e.g., you want a replacement system to generate the same addresses. >> >> Good reason IMHO. > > Was that mentioned in the requirements? I will check :-) > 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 :-) ) 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 otroan@employees.org Tue Jan 21 12:25: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 B3A821A01B4 for ; Tue, 21 Jan 2014 12:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pwZob9x0gMQz for ; Tue, 21 Jan 2014 12:25:43 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 40E301A0166 for ; Tue, 21 Jan 2014 12:25:43 -0800 (PST) Received: from [192.168.10.84] (unknown [195.159.143.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 25BCC6065; Tue, 21 Jan 2014 12:25:40 -0800 (PST) From: Ole Troan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Summary of adoption call for draft-gont-6man-deprecate-eui64-based-addresses-00 Date: Tue, 21 Jan 2014 21:25:38 +0100 Message-Id: <4D33D03E-6B84-44CA-98E5-3DF03A758320@employees.org> To: 6man WG Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) 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: Tue, 21 Jan 2014 20:25:44 -0000 There is strong consensus in the working group that for generation of = IPv6 global unicast addresses, EUI-64 based interface-identifiers should not be the default method = recommended by the IETF. There are some open questions with regards to generation of link-local = addresses, that can be dealt with in the working group after adoption. While we think there is a strong consensus to not prefer EUI-64 based = interface-identifiers, we don't think there is a consensus to "deprecate" EUI-64 based = interface-identifiers. We think that what is appropriate now is to have this document focus on = a recommendation to prefer other types of interface-identifiers such as described in I-D.ietf-6man-stable-privacy-addresses. The authors should update the document to reflect the above, and = resubmit as a working document with a new title and filename. Such as: Recommendation on Default Interface-Identifiers Best regards, Bob and Ole From lorenzo@google.com Tue Jan 21 12:34: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 521341A0245 for ; Tue, 21 Jan 2014 12:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 2yFADImmZ4Zm for ; Tue, 21 Jan 2014 12:34:56 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 507121A0221 for ; Tue, 21 Jan 2014 12:34:56 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id x13so10775426ief.9 for ; Tue, 21 Jan 2014 12:34:56 -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=H1y6RhmA6KlLxS5SMaehutfIudoiE36OvSaU5FgFWPk=; b=meWOJTQI1YpR5X7hgPGk/WoOygTNyC5QeD7/9s6UnmSLyj53r1g7L86MdWg5XUZUWu Y6TKmV31oHAW2UYHGQHF9UTKX6AxCl34VOr+UlPe6VSczFqeUhsqSuu81ovcIf0vtXON dw7gsLdnGNzpfg5/QVZN/6bWUpOlGr82RZinVdkokogEYMNuvRRM7Zd8fHTWPQCmYxV2 nJcVPqZ4UZWlT/RmKNdU3uaqdZ3EuF02r3ylDmaF8hVGVZIA+81sLJrDtCBbuOkm1bwi DgXrixZwLgVz8IdhxYROSirO8N+vHYmJUG750vej9LdW03ZDPFZD8RBuMV8rx6roxzjI SB6Q== 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=H1y6RhmA6KlLxS5SMaehutfIudoiE36OvSaU5FgFWPk=; b=S2j6tGgYtYkl962SYnP03LgLCtJ70qSw3xST3Goi8GJvmvOoYbf5yciPPB0l9iPVQR r3ZGxQh51omYWHiUk2Dws8H8xI0cw5S4tdNkmRl5fBKuGnviB4KxJfu6QIuuD0n2gWYS XShhqKgW1A8u9nBVJd1jiwo192xFtffeicspsnAKv4f2LlTrfK6hNgFtyofrny8JqcY/ KVNqT1c5n+BRe7BMPaGC4jRuMy6vvYqPSVFiS0OWwmJsJQijNHaQC97zGab5dXjKgH4P +EMAPkuPiM/P0X0hor2vzzcWZoxCGSLr3lHOQCTdd/TUe0zXqk+N+mD3ir+AsN9Bp6sy 9H6g== X-Gm-Message-State: ALoCoQlPKqzh++nnAao8TPJJM0eSqThzMeI9JnV67ginB3VPq5A2jL1LJVqsVuWkuiqzqJmtwhkOGlm6UkldJYO1ZruTdU8aoVTFr+xpMgR2UOMiC08Knq5IUEp1GyUMoa3tcBGXdJ12U/exQwcdHRrXXC8/Q0XJ3D2IgT6aR09VONlkoinOIi1ARnkeiMrHI3iGdAAdDBcb X-Received: by 10.42.156.72 with SMTP id y8mr11607029icw.25.1390336496024; Tue, 21 Jan 2014 12:34:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Tue, 21 Jan 2014 12:34:35 -0800 (PST) In-Reply-To: <52DA0ABA.8030903@acm.org> References: <52D96663.6060005@sonic.net> <52DA0ABA.8030903@acm.org> From: Lorenzo Colitti Date: Tue, 21 Jan 2014 12:34:35 -0800 Message-ID: Subject: Re: Reducing the battery impact of ND To: Erik Nordmark Content-Type: multipart/alternative; boundary=90e6ba2121f5f6ef3604f080f0f5 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG , =?UTF-8?Q?Andrew_=F0=9F=91=BD_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: Tue, 21 Jan 2014 20:34:59 -0000 --90e6ba2121f5f6ef3604f080f0f5 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 17, 2014 at 9:01 PM, Erik Nordmark wrote: > >> 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. > 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. > FWIW I don't have a problem with an opt-in update to 4861. I even think > efficient-nd is the way to go because it reduces overall ND multicast > traffic and not just your narrow focus on mobile phone battery life. The tradeoff is that efficient ND adds more state to the network about host addresses and changes a pretty core part of the IPv6 specs. I think that if we can reduce the battery impact of multicast traffic, we will have fixed most of the problem without doing either of those, and to my mind, that's a much better tradeoff. --90e6ba2121f5f6ef3604f080f0f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 17, 2014 at 9:01 PM, Erik Nordmark <nordmark@acm.org>= wrote:

=C2=A0 =C2=A0 One of your "yes please" below is a change to ND - = Andrew's b) about
=C2=A0 =C2=A0 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 wh= ich was loss issues for the initial RS. It might not be wise to expand that= drafts scope to also cover (part of) efficient-nd.

To my mind, sending an RS when the RA lifetime is about to e= xpire 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 expir= e is not necessarily a problem. But in a world where IPv6 is the main proto= col, then hosts will probably want to try harder to keep their IPv6 address= around.
=C2=A0
FWIW I don't have a pro= blem with an opt-in update to 4861. I even think efficient-nd is the way to= go because it reduces overall ND multicast traffic and not just your narro= w focus on mobile phone battery life.

The tradeoff is that efficient ND adds more state to th= e network about host addresses and changes a pretty core part of the IPv6 s= pecs. I think that if we can reduce the battery impact of multicast traffic= , we will have fixed most of the problem without doing either of those, and= to my mind, that's a much better tradeoff.
--90e6ba2121f5f6ef3604f080f0f5-- From jari.arkko@piuha.net Tue Jan 21 13:28: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 5C8E31A037B; Tue, 21 Jan 2014 13:28:40 -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, 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 aEHZrGEDxiyL; Tue, 21 Jan 2014 13:28:37 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 43D441A0250; Tue, 21 Jan 2014 13:28:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2F91D2CEB6; Tue, 21 Jan 2014 23:28:35 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2nXAAYyvW8U; Tue, 21 Jan 2014 23:28:32 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id D7D9F2CC48; Tue, 21 Jan 2014 23:28:31 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: [Gen-art] Gen-ART LC Review of draft-ietf-6man-stable-privacy-addresses-16 From: Jari Arkko In-Reply-To: <46B4DC5A-723A-49E2-992F-FA1906F228FB@nostrum.com> Date: Tue, 21 Jan 2014 23:28:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <46B4DC5A-723A-49E2-992F-FA1906F228FB@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1510) Cc: draft-ietf-6man-stable-privacy-addresses.all@tools.ietf.org, 6man@ietf.org, "gen-art@ietf.org Team \(gen-art@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 21:28:40 -0000 Ben: thanks for your review & re-review. Jari On Dec 24, 2013, at 4:31 AM, Ben Campbell wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at >=20 > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-ietf-6man-stable-privacy-addresses-16 > Reviewer: Ben Campbell > Review Date: 2013-12-23 > IETF LC End Date: 2013-12-25 >=20 > Summary: Ready for publication as a standards track RFC.=20 >=20 > Note: I performed a Gen-ART review on version 06 of this draft at a = previous IETF LC. While the draft has evolved quite a bit since then, = this review is mostly incremental to that one. All of my comments from = that review have been addressed. >=20 > Major issues: >=20 > None >=20 >=20 > Minor issues: >=20 > None >=20 > Nits/editorial comments: >=20 > None > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From otroan@employees.org Tue Jan 21 14:35: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 C8A9B1A02DC for ; Tue, 21 Jan 2014 14:35:05 -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, 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 SjCd1WAa5J3P for ; Tue, 21 Jan 2014 14:35:04 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0AF1A0256 for ; Tue, 21 Jan 2014 14:35:04 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAG/13lKQ/khN/2dsb2JhbABagwu8fYEWFnSCJQEBAQMBeQULC0ZXBogQCMJ3F44XaAeDJIEUBJA7mX+DLjs X-IronPort-AV: E=Sophos;i="4.95,697,1384300800"; d="asc'?scan'208";a="3307181" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 21 Jan 2014 22:35:03 +0000 Received: from dhcp-10-61-101-156.cisco.com (dhcp-10-61-101-156.cisco.com [10.61.101.156]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0LMZ1hK013436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Jan 2014 22:35:02 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_9F3780C8-0CDB-4861-A049-AEAFAF75C4EB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Reducing the battery impact of ND From: Ole Troan In-Reply-To: Date: Tue, 21 Jan 2014 23:35:01 +0100 Message-Id: References: <52D96663.6060005@sonic.net> <52DA0ABA.8030903@acm.org> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1827) 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: Tue, 21 Jan 2014 22:35:06 -0000 --Apple-Mail=_9F3780C8-0CDB-4861-A049-AEAFAF75C4EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Lorenzo, > One of your "yes please" below is a change to ND - Andrew's b) = about > restarting RS would require a (small) standards update. >=20 >=20 > We should try to get that into draft-6man-resilient-rs. >=20 > 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." > 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? cheers, Ole --Apple-Mail=_9F3780C8-0CDB-4861-A049-AEAFAF75C4EB 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 iQEcBAEBCgAGBQJS3vYVAAoJEFuJXizso86g2dgIANQkcH6TA4fw/P8EsxB5fncB L7J1yIUXc+XtSqsvQtfG3SKdLZ6NznynEEG2NVofrTCpYnUvEs7CAbq53HoTDY6d WBYtC3yBTet8TW5bC4ahqn20EVm7qeKt0boseWKOBBpdekqCCCdgjlYSp0e8tqMl hny3cJYnsEyrFEo1firbIF6kRf4BC3kGZ0LwO7Q8f7S0ASUqixQyGC57feP6VDrt uHYSdINbvEp+LbdvmEkv9M/2yY4DwHbb8H7O0oUJCyfzETIl/v0u06a2X3uLjpmF 3tWBuKaXpGgSDHFpT5qmvA1AmaBRbuX/bk4/ZrURMmB4WlTj1fup6l/GbsI8rgE= =tb7W -----END PGP SIGNATURE----- --Apple-Mail=_9F3780C8-0CDB-4861-A049-AEAFAF75C4EB-- From markzzzsmith@yahoo.com.au Wed Jan 22 00:33: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 B670C1A02A4 for ; Wed, 22 Jan 2014 00:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.201 X-Spam-Level: ** X-Spam-Status: No, score=2.201 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, HK_RANDOM_FROM=0.999, 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 lAcE2GKq5Qch for ; Wed, 22 Jan 2014 00:33:09 -0800 (PST) Received: from nm8-vm5.bullet.mail.ne1.yahoo.com (nm8-vm5.bullet.mail.ne1.yahoo.com [98.138.91.230]) by ietfa.amsl.com (Postfix) with ESMTP id 76BEE1A007B for ; Wed, 22 Jan 2014 00:33:09 -0800 (PST) Received: from [98.138.100.115] by nm8.bullet.mail.ne1.yahoo.com with NNFMP; 22 Jan 2014 08:33:08 -0000 Received: from [98.138.226.164] by tm106.bullet.mail.ne1.yahoo.com with NNFMP; 22 Jan 2014 08:33:08 -0000 Received: from [127.0.0.1] by omp1065.mail.ne1.yahoo.com with NNFMP; 22 Jan 2014 08:33:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 766379.48989.bm@omp1065.mail.ne1.yahoo.com Received: (qmail 5968 invoked by uid 60001); 22 Jan 2014 08:33:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1390379588; bh=WXTzASW5IKg8hAhHKNOfvlnzuNgLHvyadNCWdrOvLw8=; 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=YcXzJA2rTK22n/OeSJXn5lSg6VQVWp9tUpFpZKs9TM9bQ7uSM+qup9tNPp99r5HfwAwnUtIpwrf8URw2Ko68XBCt8KxKP9JmYcptBH64E+NDF2u/xBB3eVvvzC0rHp8L82Gl0eTHdMmfDqEeFo4Z9xrl/GPvxnEKrkQs2fcRqDA= 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=PVpWiYfefcWCIBJRr7fA+G9xpAPifytLOjynf0JsMKTzKSQ4Vp1q3mtf1Px77f3bFL/GzsrCvR6Stz4W+yWJ3eorj3hCeSFLObGyojVpZLOlI0fJXOvgDmwqQWSQLWyv4KzhAuonGICQ6+LKt85k4u0V/q2jf9cRhpEmW1wkWJ0=; X-YMail-OSG: i7_T3o4VM1lHZ9OymUSMIVZOdSOxOuWIyEhlbkUT3Uglh8F NbIkm4xPXiH03mzw7C6x2TjvGpp3tIAmXu436H83L56HNVJJnl59qM0h2evY RgF2gr_2KegAycFDdC9ACl4mf9DB8YFE60YZoexGjvgalYFAGHhU.FegVzZm oKKYp.LrgrA74LC.mFpf3Iay13RoAfgnnPBTioqMOpOLqVaZc40d_wK6FLXL 0CWmvlSYSMbNXVqJSkUqnSQ_798fXQk9RSS6I32PLRzwYPI7jvy32.Q435I0 cPcpt5wA6l1M5gk9E5E40qv8mfyH4rySNC134yNriCotX7uhsjphhqe6u8O4 s5syYbDmwHumSQ8Iugb1KLaSIYiO11tcjN.pS6m8DVWkmQ0NXSBPkJWdMMav uOmYeEk6NqOqu1m4O4g3YofdOMyRgywfl445U26JaGXrmJKhgIpJ7.ylGiNA N3ogX5nVlwMDPs4CtiYKycMOqsef65z3rSkf.tf8GFgR8mWW1tZeQVoRjHH3 _tzktvqPVynrcauAi3vE4Sl7NaptTzWXF6isaxloLPuLzFYw47OjNfkugJLJ Z9xMDHSOKg332CTUBdAyPCMS9 Received: from [150.101.221.237] by web120506.mail.ne1.yahoo.com via HTTP; Wed, 22 Jan 2014 00:33:08 PST X-Rocket-MIMEInfo: 002.001, SGkgR3JlZywKCgotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gRnJvbTogR3JlZyBEYWxleSA8Z2RhbGV5QGF1LmxvZ2ljYWxpcy5jb20.Cj4gVG86ICdNYXJrIFpaWiBTbWl0aCcgPG1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU.OyAnSW5nLVdoZXIgQ2hlbicgPGluZy13aGVyLmNoZW5AZXJpY3Nzb24uY29tPjsgImlwdjZAaWV0Zi5vcmciIDxpcHY2QGlldGYub3JnPgo.IENjOiAKPiBTZW50OiBNb25kYXksIDIwIEphbnVhcnkgMjAxNCA5OjUwIEFNCj4gU3ViamVjdDogUkU6IE5ldyBWZXJzaW9uIE4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.173.622 References: <20140111004402.10451.90724.idtracker@ietfa.amsl.com> <72381AF1F18BAE4F890A0813768D992817FCA84E@sdcexchms.au.logicalis.com> <1390035508.23310.YahooMailNeo@web120503.mail.ne1.yahoo.com> <72381AF1F18BAE4F890A0813768D992817FCDDEC@sdcexchms.au.logicalis.com> Message-ID: <1390379588.46492.YahooMailNeo@web120506.mail.ne1.yahoo.com> Date: Wed, 22 Jan 2014 00:33:08 -0800 (PST) From: Mark ZZZ Smith Subject: Re: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt To: Greg Daley , 'Ing-Wher Chen' , "ipv6@ietf.org" In-Reply-To: <72381AF1F18BAE4F890A0813768D992817FCDDEC@sdcexchms.au.logicalis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.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, 22 Jan 2014 08:33:11 -0000 Hi Greg,=0A=0A=0A----- Original Message -----=0A> From: Greg Daley =0A> To: 'Mark ZZZ Smith' ; 'In= g-Wher Chen' ; "ipv6@ietf.org" = =0A> Cc: =0A> Sent: Monday, 20 January 2014 9:50 AM=0A> Subject: RE: New Ve= rsion Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt=0A> = =0A> Hi Mark, =0A> =0A> When we were looking at accelerating DAD for mobile= nodes a while ago, I =0A> investigated the state held by MLD and wrote a d= raft.=0A> (Now expired http://tools.ietf.org/html/draft-daley-ipv6-mcast-da= d-02)=0A> =0A> A much better solution was found (now RFC 4429), but the con= sistent state =0A> keeping by the MLD querier (and other routers) is still = present (particularly =0A> for MLDv2).=0A> =0A> (I am now thinking out loud= , so please bear with me)=0A> =0A> The difference is that the solicited nod= es' address was not identical to an =0A> address binding and that (after li= stener state synchronization) only the =0A> non-presence of an MLD listener= on the solicited nodes address could be used to =0A> prove the address was= absent.=A0 For relatively sparse links and subnets this =0A> would allow t= he router to state explicitly that the address was not in use.=0A> =0A> For= ND cache protection, the presence of any MLD listener on the solicited =0A= > nodes' activates the group, and no-listeners means there isn't even a =0A= > reason to transmit the neighbour solicitation.=0A>=A0=0A=0AExactly.=0A=0A= > Unless the router maintains additional ND cache state, it cannot distingu= ish =0A> between an activated group and which of the addresses is active, a= nd thus a =0A> subset of the addresses (e.g. the globally routable equivale= nt of a Link-local =0A> address with a particular solicited nodes [and anyt= hing with the same IID lower =0A> order bits]).=0A>=A0=0A=0ATrue. The prese= nce of a solicited-node group on a link only indicates at least one of the = addresses that would map to it is present.=0A=0A> Is this sufficient protec= tion, or does there have to be more specific state =0A> gathered in the ND = cache, perhaps through the discussed draft?=0A>=A0=0A=0AI see this idea as = another quite useful mitigation, but certainly not a prevention of the ND c= ache DoS attack.=0A=0AAs the number of present solicited-node groups is ver= y unlikely to ever exceed 1% of the total available solicited-node groups (= 2^24/16M), that means that NSes don't have to be performed for destination = addresses that map the the remaining 99% of solicited-node groups. This is = in comparison to today where NSes would be performed for any unknown destin= ation within the /64. I think that would be another measure that usefully r= educes the effectiveness of the off-link ND cache DoS attack against a rout= er. Less predictable solicited-node groups, as a result of=A0draft-ietf-6ma= n-stable-privacy-addresses, would further reduce the effectiveness of the o= ff-link ND cache DoS.=0A=0A=0AI though of this idea while thinking about ho= w MLD/solicited-node group membership might be able used to facilitate node= registration, preventing the router ND cache DoS attack. It previously occ= urred to me that if nodes are using MLDv2, meaning that all nodes report th= eir membership of all groups, then routers tracking solicited-node membersh= ip would now have knowledge of one of all of the attached nodes' link-local= addresses (either as the nodes initialise their addresses, or because a ro= uter initiates a querier election when it initialises) . If the nodes then = supported Inverse ND+, then the routers could query the nodes for their oth= er addresses, giving them complete knowledge of all unicast addresses on al= l nodes, achieving complete node registration. NUD would then take care of = expiring node registrations when the nodes disappear.=A0=0A=0AThis method w= ouldn't achieve the efficiency goals of=A0draft-chakrabarti-nordmark-6man-e= fficient-nd. I think its value would be that it leverages existing mechanis= ms such as MLDv2 and Inverse ND, and would have a relatively low implementa= tion cost.=0A=0ARegards,=0AMark.=0A=0A=0A+ =A0or perhaps RFC4620 Node Infor= mation Queries, although I think Inverse ND might be better because it is l= ikely to be simpler to implement, and isn't Experimental.=0A=0A=0A=0A=0A> S= incerely, =0A> =0A> Greg Daley=0A> =0A> =0A> =0A> =0A> -----Original Messag= e-----=0A> From: Mark ZZZ Smith [mailto:markzzzsmith@yahoo.com.au] =0A> Sen= t: Saturday, 18 January 2014 7:58 PM=0A> To: Greg Daley; 'Ing-Wher Chen'; i= pv6@ietf.org=0A> Subject: Re: New Version Notification for =0A> draft-halpe= rn-6man-nd-pre-resolve-addr-00.txt=0A> =0A> =0A> =0A> =0A> =0A> ----- Origi= nal Message -----=0A>>=A0=A0From: Greg Daley =0A>>= =A0=A0To: 'Ing-Wher Chen' ; =0A> "ipv6@ietf.org= " =0A>>=A0=A0=0A>>=A0=A0Cc: =0A>>=A0=A0Sent: Friday, 17 Janu= ary 2014 1:14 PM=0A>>=A0=A0Subject: RE: New Version Notification for =0A>>= =A0=A0draft-halpern-6man-nd-pre-resolve-addr-00.txt=0A>> =0A>>=A0=A0Hi Hele= n,=0A>> =0A> =0A> =0A>> =0A>>=A0=A03/ Monitor the solicited nodes' ad= dresses in the MLD querier router, =0A>>=A0=A0and do not transmit an NS fro= m off-link for an incomplete address =0A>>=A0=A0unless someone is listening= .=0A>> =0A> =0A> So I've been thinking for the last few months that this me= thod could be a =0A> useful further mitigation to off-link ND cache attacks= for routers. I've =0A> been writing something up which I've been planning = to finish and post in the =0A> next week or so.=0A> =0A> I think it could b= e fairly effective - there are a total possible 2^24 =0A> solicited-node mu= lticast groups on a link, where as there will only be as many =0A> present = ones as there are IIDs with unique lower 24 bits. For most subnets I =0A> t= hink that will number in the order of 10s or 100s, and perhaps on rare =0A>= occasions in the low 1000s. So NSes would only be necessary for e.g. 1000/= 2^24 =0A> portion of the unicast address space, otherwise the packets that = would trigger =0A> them can be dropped (or perhaps sent to an RFC6018 greyn= et collector).=0A> =0A> A neighbor cache attack is likely to be still be po= ssible for the 2^40 portions =0A> of unicast address space covered by each = of the the present solicited-multicast =0A> groups, however Fernando's Stab= le/Opaque IID draft would make them harder to =0A> find, even though it wil= l increase the number of them, as there is an unique =0A> Opaque IID per pr= efix.=0A> =0A> All routers listening to MLD track group membership, not jus= t the MLD querier, =0A> so all routers on the link could implement this met= hod.=0A> =0A> Regards,=0A> Mark.=0A> From presnick@qti.qualcomm.com Wed Jan 22 07:57: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 D4DCD1A02D9; Wed, 22 Jan 2014 07:57:26 -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 QMdwYw248LSY; Wed, 22 Jan 2014 07:57:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5651A010D; Wed, 22 Jan 2014 07:57:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Pete Resnick" To: The IESG Subject: Pete Resnick's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS) X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140122155725.24467.53781.idtracker@ietfa.amsl.com> Date: Wed, 22 Jan 2014 07:57:25 -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: Wed, 22 Jan 2014 15:57:27 -0000 Pete Resnick has entered the following ballot position for draft-ietf-6man-stable-privacy-addresses-16: Discuss 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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'd like to hear mostly from the shepherd, who didn't actually answer the second part of the first question on the shepherd writeup: "Why is this the proper type of RFC?" This looks to me like an algorithm to generate stable, private, and mostly unique addresses. It looks like it does not affect interoperability at all if people choose a different method. It looks to me like you could have accomplished the same task in a number of different ways. This just seems like a nice method to use if someone wanted to use it. So it's not clear to me why this isn't just an Informational document explaining a nice way to generate stable, private, mostly unique addresses without lots of MUSTs and SHOULDs that are not really interoperability requirements. From bob.hinden@gmail.com Wed Jan 22 09:24: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 75D4A1A0160; Wed, 22 Jan 2014 09:24:06 -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 GQwdJPe4dzbz; Wed, 22 Jan 2014 09:24:01 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 66F9B1A011B; Wed, 22 Jan 2014 09:24:01 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id cc10so855623wib.17 for ; Wed, 22 Jan 2014 09:24:00 -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 :message-id:references:to; bh=KzcRIsExp8qPrJym0NWOGaISRXy2K6NnLeh/x5HBkNA=; b=DeiVVm8KJeM52vzM3ITZbCnCyaiAkHSLk/VTtiAAiMEVICCN2FNhZHAtOz1fJ1XL/b g6bbxiZ16HhTsGlweDzgF/bZAkCistu1q55KqweTJUB12wasF04NKx3OyWMCwxj3idrq oEqVFE4k3/nYylDsRlUxhvc2GRh4a/keKlXybypA5scqVx+Tb08cfqddbVyHXwc3LBoV itFhxT+s1WkBMDzhh9F32d9ABVLFTduz+9IWdszwQQ33ClipFe7MlUtyhrLF4aHcpBHQ 21E2unflx7KrA5lHRNWZIVNGM2BEhuJaXuqVo/7zD7yzzdNnqkCPztlBWluUwT45dZYH 8X+w== X-Received: by 10.194.2.70 with SMTP id 6mr2876132wjs.25.1390411440432; Wed, 22 Jan 2014 09:24:00 -0800 (PST) Received: from ?IPv6:2601:9:4080:10:b124:c2b4:2e0a:a4e9? ([2601:9:4080:10:b124:c2b4:2e0a:a4e9]) by mx.google.com with ESMTPSA id ff9sm20563510wib.11.2014.01.22.09.23.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jan 2014 09:23:58 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_97C6F1E2-EF69-4D8D-A6D5-C67175204827"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Pete Resnick's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS) From: Bob Hinden In-Reply-To: <20140122155725.24467.53781.idtracker@ietfa.amsl.com> Date: Wed, 22 Jan 2014 09:23:47 -0800 Message-Id: <918429AA-4527-4EBC-88B8-A1DDB0C93886@gmail.com> References: <20140122155725.24467.53781.idtracker@ietfa.amsl.com> To: Pete Resnick X-Mailer: Apple Mail (2.1510) Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, Bob Hinden , The IESG , 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, 22 Jan 2014 17:24:06 -0000 --Apple-Mail=_97C6F1E2-EF69-4D8D-A6D5-C67175204827 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Pete, > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I'd like to hear mostly from the shepherd, who didn't actually answer = the > second part of the first question on the shepherd writeup: "Why is = this > the proper type of RFC?" I am the document shepherd for this document. >=20 > This looks to me like an algorithm to generate stable, private, and > mostly unique addresses. It looks like it does not affect > interoperability at all if people choose a different method. It looks = to > me like you could have accomplished the same task in a number of > different ways. This just seems like a nice method to use if someone > wanted to use it. So it's not clear to me why this isn't just an > Informational document explaining a nice way to generate stable, = private, > mostly unique addresses without lots of MUSTs and SHOULDs that are not > really interoperability requirements. >=20 Several reasons why I think Proposed Standard is appropriate. The properties for IPv6 interface-identifiers are defined in RFC4291, = currently at Draft Standard. This includes several types of = interface-identifiers including EUI-64 based interface-identifiers. = Other types of interface-identifers, such as temporary addresses, SEND = CGA, etc., are defined in other standards track RFCs. This document is = consistent with this. The working group is also working on a recommendation to make Stable = Privacy interface-identifiers the default, instead of EUI-64 based = interface-identifiers. The working group is also discussing if it wants = to deprecate the EUI-64 based interface-identifiers. See:=20 = http://datatracker.ietf.org/doc/draft-gont-6man-deprecate-eui64-based-addr= esses/ This is currently in an adoption call, please see the email on the = ipv6@ietf.org list. I think it would be confusing to prefer an = Informational RFC over Standards track. Hope this answers your question. Thanks, Bob --Apple-Mail=_97C6F1E2-EF69-4D8D-A6D5-C67175204827 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 iQEcBAEBCgAGBQJS3/6jAAoJEK7rdBF357uo6eYIAKBh1VVzRoaAOLwWZc2XOMf6 0EyO3RJYe+7ODWz9b7dP3ru7cQ6Fyc8XbXbTLMPSN3gw74ZSFzFRkf9cnjqrC7e2 CejMsh33BLlKWb/Rs/fpzES0iqT6NLZXDm1TUUVB75HsHNMsBC8DGTndFZWdPFda qeneZ+i7FYyF6whR0KiVd7MgUOAUazlx3M8bD9Y54V63PmRFf3DNfcuGpNF4KxOP SpRsJlbWGrBaowF7YeuocbsuNY3IotqHqoTETO055OEDXYpuC4gm7M2zDXuCQNdF QA4q1leUNXCslPlj8+5V15PnrluihLVmmVxIOlOyMZyo1RUlgoanPyhAw9DbC8A= =OXG3 -----END PGP SIGNATURE----- --Apple-Mail=_97C6F1E2-EF69-4D8D-A6D5-C67175204827-- From narten@us.ibm.com Wed Jan 22 10:36: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 0B9E81A018B for ; Wed, 22 Jan 2014 10:36:26 -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 ni_OcXKXlwVm for ; Wed, 22 Jan 2014 10:36:22 -0800 (PST) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 98C241A01D9 for ; Wed, 22 Jan 2014 10:36:11 -0800 (PST) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 22 Jan 2014 13:36:09 -0500 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 22 Jan 2014 13:36:08 -0500 Received: from b01cxnp22034.gho.pok.ibm.com (b01cxnp22034.gho.pok.ibm.com [9.57.198.24]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 1BFCA6E8048 for ; Wed, 22 Jan 2014 13:36:04 -0500 (EST) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by b01cxnp22034.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s0MIa84S9044262 for ; Wed, 22 Jan 2014 18:36:08 GMT Received: from d01av01.pok.ibm.com (localhost [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s0MIa7KA030688 for ; Wed, 22 Jan 2014 13:36:07 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-92-95.mts.ibm.com [9.65.92.95]) by d01av01.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s0MIa6aL030636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Jan 2014 13:36:07 -0500 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 s0MIa5lo002885 for ; Wed, 22 Jan 2014 13:36:05 -0500 Date: Wed, 22 Jan 2014 13:36:05 -0500 Message-ID: From: Thomas Narten To: ipv6@ietf.org Subject: Review of draft-ietf-6man-stable-privacy-addresses-16.txt 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: 14012218-0320-0000-0000-000002429F5C 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 18:36:26 -0000 Note: I haven't been following this work and haven't read the document since its initial version. Overall, I think this document is a good thing and should move forward. I have a number of general comments. First, I'm surprised this document doesn't reference any of the DNA work (RFC 4436 & 6059). That work is all about determining whether you've attached to the same network as one you've attached to before and reusing the same network parameters if you do. Given that this document is about using the same IID when connecting to the same network... This seems like an oversight. I.e., shouldn't some of the same approaches for determining what network you are on be leveraged? Two things come to mind. If you have stable storage (and many devices do), it makes sense to just cache the addresses instead of regenerating them. DNA does this. Seems like that option should be allowed. (the current document suggests saving the number of DAD iterations in stable storage... why do that if you can just save the address itself?) Second, DNA also has recommendations for detecting when you (re)connect to a network you visited before. That is pretty much the same thing this spec needs to do in order to generate the same addresses when connecting to a previously visited network (i.e., the Network_ID paramater). For the wired case (i.e, no SSID), DNA suggests using the linklayer/linklocal address pair of routers to identify a link. This document might suggest doing the same thing. Seems this spec might benefit from a clearer applicability statement. There seem to be two motivations for the document: 1) mitigate off-site scanning attacks and 2) making it harder to track devices that move. The second item seems of interest (only) to personally owned devices, those that are typically owned by a single user and are (at least somewhat) mobile. For other types of devices (e.g., those typically found in data centers), I suspect this motivation is not compelling. I think it would be good to make this more clear. On mitigating address scanning attacks, that will be of interest to some folk. But I suspect there are others that won't care all that much. What I think this spec should be clear about is that it is optional, and give guidance for those scenarios where it is potentially useful. Finally, I want to raise a generic issue that applies to this document, but really is a general problem. The document adds a random delay between 0 and IDGEN_DELAY in order to avoid lock-step behavior. While that is a good thing, Using IDGEN_DELAY of 1 second is pretty long for some network technologies (think data center with 10G or higher interfaces). I wonder if we should stop using constants that are fixed and make them more dependent on actual network technology. E.g., 1 second seems OK for WiFi, but not for 10G. Likewise, should you ever stop trying to configure an address if you keep getting DAD failures? I'm of two minds. Going forward, it becomes increasingly painful to require operator intervention to "fix" something that isn't working. That argues for never giving up. But what should happen then is some sort of exponential backoff should be used to ensure that retries happen infrequently, so as not to cause network problems. The current text says: > We also > note that hosts MUST limit the number of tentative addresses that are > tried (rather than indefinitely try a new tentative address until the > conflict is resolved). But that is pretty vague advice. That all said, if you have a device with a (broken) implementation, having it try over and over again makes no sense either. Editorial comments: > However, implementations conforming to > this specification MAY employ the algorithm specified in [RFC4941] to > generate temporary addresses in addition to the addresses generated > with the algorithm specified in this document. reword to say something like "MAY employ other alogorithms for generating additional temporary addresses (e.g., RFC4941])." The MAY should make it clear that other approaches are allowed, with 4941 being one example. Rather than suggesting only that RFC4941 MAY be implemented. Network_ID: Some network specific data that identifies the subnet to which this interface is attached. For example the IEEE 802.11 Service Set Identifier (SSID) corresponding to the network to which this interface is associated. This parameter is OPTIONAL. RFC6059 (DNAv6) may be useful here. It has the notion of identifying a link by a combination of the routers Link-local + Link Layer address. Local Addresses (ULAs). In those scenarios where the Network_ID is unknown to the attacker, including this parameter might help mitigate attacks where a victim node connects to the same subnet as the attacker, and the attacker tries to learn the Interface Identifier used by the victim node for a remote network (see Section 9 for further details). add reference to ULAs on first use of term. Finally, we note that all of the bits in the resulting Interface IDs are treated as "opaque" bits [I-D.ietf-6man-ug]. For example, the universal/local bit of Modified EUI-64 format identifiers is treated as any other bit of such identifier. In theory, this might result in Duplicate Address Detection (DAD) failures that would otherwise not be encountered. However, this is not deemed as a real issue, because of the following considerations: Wording is awkward about DAD failures...wording suggests the problem is DAD. Actually, the problem is that failures lead to duplicate addresses -- that is the real issue. That DAD catches them is a good thing. NEW TEXT: In theory, this might result in address formation collisions and Duplicate Address Detection (DAD) failures that would otherwise not be encountered. However, this is not deemed as a real issue, because of the following considerations: also, s/real issue/likely issue/ It will be a very "real" issue when it happens, e.g., as it likely will when implementations mess up! o Since some popular and widely-deployed operating systems (such as Microsoft Windows) do not employ unique hardware addresses for the Interface IDs of their stable addresses, reliance on such unique identifiers is more reduced in the deployed world (fewer deployed systems rely on them for the avoidance of address collisions). wording is awkward. what are "unique hardware addresses"? Do you mean standard SLAAC? Also, what are you trying to say above? that because windows doesn't do SLAAC, and things didn't break, something isn't an issue? That's not much of a justification, and should maybe just be deleted. This procedure may be repeated a number of times until the address conflict is resolved. Hosts SHOULD try at least IDGEN_RETRIES (see Section 7) tentative addresses if DAD fails for successive generated addresses, in the hopes of resolving the address conflict. We also note that hosts MUST limit the number of tentative addresses that are tried (rather than indefinitely try a new tentative address until the conflict is resolved). wonder if it would be better to specify some rate limiting that makes sense. In those unlikely scenarios in which duplicate addresses are detected and in which the order in which the conflicting nodes configure their addresses may vary (e.g., because they may be bootstrapped in different order), the algorithm specified in this section for resolving DAD conflicts could lead to addresses that are not stable within the same subnet. In order to mitigate this potential problem, nodes MAY record the DAD_Counter value employed for a specific {Prefix, Net_Iface, Network_ID} tuple in non-volatile memory, such that the same DAD_Counter value is employed when configuring an address for the same Prefix and subnet at any other point in time. if you have non-volatle memory, wouldn't it just make more sense to save the address you generated before? I.e., that is what DNA does... In the event that a DAD conflict cannot be solved (possibly after trying a number of different addresses), address configuration would fail. In those scenarios, nodes MUST NOT automatically fall back to employing other algorithms for generating Interface Identifiers. why not? Hosts SHOULD introduce a random delay between 0 and IDGEN_DELAY seconds (see Section 7) before trying a new tentative address, to avoid lock-step behavior of multiple hosts. IDGEN_DELAY of 1 sec is too long for some network technologies. Need to put in a reference to ULA spec. From narten@us.ibm.com Wed Jan 22 10:55: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 80F451A0154 for ; Wed, 22 Jan 2014 10:55:34 -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 57Gz-vjX1bcC for ; Wed, 22 Jan 2014 10:55:33 -0800 (PST) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 1F39C1A013A for ; Wed, 22 Jan 2014 10:55:33 -0800 (PST) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 22 Jan 2014 13:55:32 -0500 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 22 Jan 2014 13:55:29 -0500 Received: from b01cxnp22036.gho.pok.ibm.com (b01cxnp22036.gho.pok.ibm.com [9.57.198.26]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 4FA7E6E8048 for ; Wed, 22 Jan 2014 13:55:25 -0500 (EST) Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by b01cxnp22036.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s0MItTOw6488526 for ; Wed, 22 Jan 2014 18:55:29 GMT Received: from d01av05.pok.ibm.com (localhost [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s0MItToa000356 for ; Wed, 22 Jan 2014 13:55:29 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-92-95.mts.ibm.com [9.65.92.95]) by d01av05.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s0MItSxb000343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Jan 2014 13:55:28 -0500 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 s0MItRjg006080 for ; Wed, 22 Jan 2014 13:55:28 -0500 Date: Wed, 22 Jan 2014 13:55:27 -0500 Message-ID: From: Thomas Narten To: ipv6@ietf.org Subject: revisit protocol constants ?? 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: 14012218-0320-0000-0000-00000242AA5E 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 18:55:34 -0000 Here is an excerpt from my review of the stable addresses document. I wonder if we should rethink some of the protocol constants we are defining. The world is becoming more diverse and it seems that a "one size fits all" notion for some protocol constants is making less and less sense. > Finally, I want to raise a generic issue that applies to this > document, but really is a general problem. The document adds a random > delay between 0 and IDGEN_DELAY in order to avoid lock-step > behavior. While that is a good thing, Using IDGEN_DELAY of 1 second is > pretty long for some network technologies (think data center with 10G > or higher interfaces). I wonder if we should stop using constants that > are fixed and make them more dependent on actual network > technology. E.g., 1 second seems OK for WiFi, but not for 10G. Note that this sort of constant being as long as a second can mean it will take that much longer to configure an address (in some cases)... > Likewise, should you ever stop trying to configure an address if you > keep getting DAD failures? I'm of two minds. Going forward, it becomes > increasingly painful to require operator intervention to "fix" > something that isn't working. That argues for never giving up. But > what should happen then is some sort of exponential backoff should be > used to ensure that retries happen infrequently, so as not to cause > network problems. The current text says: For this, I was partly also thinking about DHCPv6 where the original spec called for the client giving up after a certain number of tries. That saves bandwidth, but it also means that if a client can't find a DHC server, at some point it quits trying and won't ever try again. And if the machine stays up and running for several weeks... (I'm not sure this ever even got fixed....) Thomas From rdroms.ietf@gmail.com Wed Jan 22 11:10: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 6D8C81A01DF for ; Wed, 22 Jan 2014 11:10:56 -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 mv5i4za94acj for ; Wed, 22 Jan 2014 11:10:54 -0800 (PST) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5851E1A01AC for ; Wed, 22 Jan 2014 11:10:54 -0800 (PST) Received: by mail-pb0-f54.google.com with SMTP id uo5so796154pbc.13 for ; Wed, 22 Jan 2014 11:10:54 -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=xTktViU45Oi9uWehQQS7jrdfaA/4qIQPfWxwEVtE7Kc=; b=DhlpWd/C8XRn4cXr/0NqekcGD7miKRZxE7ZQ+TeZg8ML+KDDrRK9TtYiYuLVyHsPoB ig3c/buhhl+KtuLzPS2RqVyrfVrIPsCzJyKsBToOWkEfPUAiX3bP4ZVVqfwzn7RnFLEb n8ZX7rlmu2vYcx040fVynzGoGMg9kVTfWQkHV0MISiROxQsBIK9vbbJSuPNhiy7izYiR mwDmDVkYnxCQW9ZPzZLceqKJm+j6B7h6GSa929hp/e02/d5Ap2B0LGDwmThipHu7PzqL RTsJfKLyrDdnlweBE9MSd+47e6KSIxGGP6tL5eVPvMi0eM0jE7uRMRE6FGdF7KIyCXgt Ho7w== X-Received: by 10.66.249.202 with SMTP id yw10mr3262821pac.111.1390417853935; Wed, 22 Jan 2014 11:10:53 -0800 (PST) Received: from [10.155.120.123] (128-107-239-234.cisco.com. [128.107.239.234]) by mx.google.com with ESMTPSA id db3sm26409259pbb.10.2014.01.22.11.10.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jan 2014 11:10:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: revisit protocol constants ?? From: Ralph Droms In-Reply-To: Date: Wed, 22 Jan 2014 11:10:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <575F16E6-BF45-43A6-B39A-440825EE60E7@gmail.com> References: To: Thomas Narten X-Mailer: Apple Mail (2.1510) 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, 22 Jan 2014 19:10:56 -0000 On Jan 22, 2014, at 10:55 AM 1/22/14, Thomas Narten = wrote: >> [...] >=20 > For this, I was partly also thinking about DHCPv6 where the original > spec called for the client giving up after a certain number of > tries. That saves bandwidth, but it also means that if a client can't > find a DHC server, at some point it quits trying and won't ever try > again. And if the machine stays up and running for several > weeks... (I'm not sure this ever even got fixed....) It's fixed. Based on sections 14 and 17.1.2, "the client continues to = transmit the message until it receives a response" (in this specific = case, a SOLICIT message). This behavior (the interval between transmissions of the SOLICIT = message) was modified with the recent publication of RFC 7083. - Ralph >=20 > Thomas >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From presnick@qti.qualcomm.com Wed Jan 22 11:20: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 C3FD81A03C4; Wed, 22 Jan 2014 11:20:19 -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 udMQRS7I6M_a; Wed, 22 Jan 2014 11:20:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 594D91A018B; Wed, 22 Jan 2014 11:20:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Pete Resnick" To: The IESG Subject: Pete Resnick's Abstain 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: <20140122192018.8692.82071.idtracker@ietfa.amsl.com> Date: Wed, 22 Jan 2014 11:20:18 -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: Wed, 22 Jan 2014 19:20:20 -0000 Pete Resnick has entered the following ballot position for draft-ietf-6man-stable-privacy-addresses-16: Abstain 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 an algorithm to generate stable, private, and mostly unique addresses. It does not affect interoperability at all if people choose a different method. Anyone can accomplish the same task in a number of different ways. This is just a nice method to use if someone wanted to use it. This should just be an Informational document explaining a nice way to generate stable, private, mostly unique addresses without all of the MUSTs and SHOULDs, which are not interoperability requirements in the first place. Standardizing this is silly in the extreme. From lorenzo@google.com Wed Jan 22 11:46:52 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 125F91A0172 for ; Wed, 22 Jan 2014 11:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 xu57WVrSBSnO for ; Wed, 22 Jan 2014 11:46:50 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5816D1A019F for ; Wed, 22 Jan 2014 11:46:50 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id lx4so5175186iec.27 for ; Wed, 22 Jan 2014 11:46:49 -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=ZoeI8ySrx6NWAT/7jQYOIUrHee4RgJoRB7eWD39MXyo=; b=HTQnf6BxBmk9LNQk5Vz9u10l+4JhFx9XT/AMLua/tumovlfYe9wkkhVM6+CRiXkKon rnh87cpqQUhcPBlXQzmLDVpsuELIH0myTmDS06p69pRqP/BZpqewI4DN8FB+6hHsDKfM FScGvI/tneOBpvpeuflj+0SbbUpXh2FZkbzMEIyp8s374FlBZXWwZmHQh3/+uvxfPjdB qiCHbNJ28JsZcLREhN//f2C8fdkO/B9NpoIqlUc/5gVhtoY1mkIDv+X8woH4/be52hZC IbrpwGNeIM70XpmHo38NGwfB30bWbWVccdKtTPbLOI91OXzEsrJYf8+4txJlfCq9warD zkRg== 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=ZoeI8ySrx6NWAT/7jQYOIUrHee4RgJoRB7eWD39MXyo=; b=TQlKzJ33Rsx52E+Rdqvb/aNB1IiuMs9/k3pcg+XO8htzQZT1NP7zX34RXxCK0uYRwY qpxYSXaivTiro1pm5tNVbKHr5K77r9/5cuYu6tSx55pCjGJZrH6mmckS4UTmKqsOrGb3 qxyrbkL6/dKr7W3xoI/sDscv83HJ2sAZM9Q3AxhjrTmR9V+03NitkA70f5b0p3Kcy82f 7dkfsSY6ms9VD8dMxHqi3NkAIT8yhxnt7zqJy+M/Yy8/F2fjQBi92s+agXoR139Nem8E mN57+c2gJTc6DmGfknJo31YWKq7jsKQJxGKmFUT8en/NbyKsQAvaumMFcj6lRoKVMR1L FZXA== X-Gm-Message-State: ALoCoQnoB8PW9INT4VSWV0ggkJGLlOTNHas7iTKHVZyZKbGHVekpPzocy7Ftfly8og+1PeB4srXGYOzpqlf3XocjVGfGObYyqe5KtQGRCj85wjR92ZXtGIXMzcrlx77pShbDK95FVq1pUWN8ayfxoolC220MeZtna9CrsB7DTtXYB1aBHAeKPXW8jSOx/IfUlG1mcxmGPHXI X-Received: by 10.43.103.5 with SMTP id dg5mr2728201icc.50.1390420009629; Wed, 22 Jan 2014 11:46:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 22 Jan 2014 11:46:29 -0800 (PST) In-Reply-To: <20131021233827.32495.34424.idtracker@ietfa.amsl.com> References: <20131021233827.32495.34424.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Wed, 22 Jan 2014 11:46:29 -0800 Message-ID: Subject: Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt To: IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary=bcaec5171b93c3586904f0946284 Cc: draft-ietf-6man-resilient-rs@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, 22 Jan 2014 19:46:52 -0000 --bcaec5171b93c3586904f0946284 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 21, 2013 at 4:38 PM, wrote: > When an interface on a host is initialized, the host transmits Router > Solicitations in order to minimize the amount of time it needs to > wait until the next unsolicited multicast Router Advertisement is > received. In certain scenarios, these router solicitations > transmitted by the host might be lost. This document specifies a > mechanism for hosts to cope with the loss of the initial Router > Solicitations. 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. > Authors, One comment here. If the intent is that we should be able to run networks that do not send periodic RAs at all, then this document will need to require that hosts send router solicitations when their RAs (or whatever is in the RA contents, including lifetimes of PIOs, RIOs, RDNSS options, etc.) are about to expire - otherwise the hosts will lose connectivity. This may be difficult to specify correctly. Specifically, it may be hard to distinguish something that is being deprecated by the network (e.g., an RA whose lifetime is counting down because it comes from a PD) from an RA that is about to expire. If the intent is not that we should be able to run networks without periodic RAs, then at least the text in 2b needs to change. Cheers, Lorenzo --bcaec5171b93c3586904f0946284 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Oct 21, 2013 at 4:38 PM, <internet-drafts@ietf.org> wrote:
=C2=A0 =C2=A0When an interface on a host is = initialized, the host transmits Router
=C2=A0 =C2=A0Solicitations in order to minimize the amount of time it needs= to
=C2=A0 =C2=A0wait until the next unsolicited multicast Router Advertisement= is
=C2=A0 =C2=A0received. =C2=A0In certain scenarios, these router solicitatio= ns
=C2=A0 =C2=A0transmitted by the host might be lost. =C2=A0This document spe= cifies a
=C2=A0 =C2=A0mechanism for hosts to cope with the loss of the initial Route= r
=C2=A0 =C2=A0Solicitations. =C2=A0Furthermore, on some links, unsolicited m= ulticast
=C2=A0 =C2=A0Router Advertisements are never sent and the mechanism in this=
=C2=A0 =C2=A0document is intended to work even in such scenarios.

Authors,

One comment he= re.

If the intent is that we should be able to run= networks that do not send periodic RAs at all, then this document will nee= d to require that hosts send router solicitations when their RAs (or whatev= er is in the RA contents, including lifetimes of PIOs, RIOs, RDNSS options,= etc.) are about to expire - otherwise the hosts will lose connectivity.

This may be difficult to specify correctly. Speci= fically, it may be hard to distinguish something that is being deprecated b= y the network (e.g., an RA whose lifetime is counting down because it comes= from a PD) from an RA that is about to expire.

If the intent is not that we should be able to run netw= orks without periodic RAs, then at least the text in 2b needs to change.

Cheers,
Lorenzo
--bcaec5171b93c3586904f0946284-- From lorenzo@google.com Wed Jan 22 11:55: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 190CF1A014E for ; Wed, 22 Jan 2014 11:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 X1J5kz1DF6De for ; Wed, 22 Jan 2014 11:55:34 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BB9781A0149 for ; Wed, 22 Jan 2014 11:55:34 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id ar20so7270327iec.6 for ; Wed, 22 Jan 2014 11:55:34 -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=rzbQgwmaF6NNXGKUHy78ttmaGzI7iV17FcoIYRIZ+Xc=; b=WybpEZnTebL3yAvIQJVQhalm4MSpmNJd74hWQcCHyKnIfy6Nct15GCiKB/PpbYbjKV sKz7b0jff+GUWH5JdysUQzZdd7bYSdIAXP80dMaRVUxI8HmPLegqEGANmgTDRN/Fl770 TZY9bQvtcD//4CBuwtiY19Jhn0SkvBoexKzh9rwC4JVqpQT9KmwVrEl67yV6cvekH6lH qRmR3PU/2yzgDuyfCwjyYcxB2Bq8da0AScou+PZeOcSN8Fj/pgpH51DnPLHglqvweCAp yWSCjyJDY7F+i6LbbZwP+m/d//pnyJ6PtiITlQ6TilRczXgw4cJ3m2Pna7UbdgjmidBE S1bA== 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=rzbQgwmaF6NNXGKUHy78ttmaGzI7iV17FcoIYRIZ+Xc=; b=CLFUovMdTkfvqhLNnFW9YpyV12cod1bckOPIQxOU6h73Fgo2k1nPpIQvG4RBYW4bUo 4vXMAmhnWBT0T9VZJITrDeSvPhrH6XMNTIYXIpunsqLJHZFkYVC+oWP7tNb5qVaNmtMe ep7lCQSAAjhwSl//DMHdgTplLC8LpPKv92lc+8KL2NEByZ7opYVl7wZ7eQGzdGsus1ra E1D1dr21OSrM82+Sc2bkgtM7BZFA16r4ki/cpQHLERaTKa2rgvyYQefSYgicsFCGyhNU lorEW6vNDdl64X70NkPqFUxiy+oFkncW3fEEWMB/WBMLOA/uRFXS2qVOuSH23/cI5W+R BLeg== X-Gm-Message-State: ALoCoQk87M3vC9TQRpPYgBUYQoTaY9xWNnTl6y3D5QuVoZxz9CLy4TwNnIfm7Xj8Bn0mylCVONa3tL/q9mPS1kXa2fmrzdCj0w/9BkXPcjLofhkjG/ZU4iEEopeSdRpIXncCKq5rR+rtcaE9/x47x3pUdIvGsogNFqj15uCgo2jJH212cNcqgVQWuvHCxYNPjWs1mq7ZxKzR X-Received: by 10.50.238.162 with SMTP id vl2mr4887631igc.45.1390420533926; Wed, 22 Jan 2014 11:55:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 22 Jan 2014 11:55:13 -0800 (PST) In-Reply-To: References: <20131021233827.32495.34424.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Wed, 22 Jan 2014 11:55:13 -0800 Message-ID: Subject: Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt To: IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary=001a11335cfc03911d04f0948264 Cc: draft-ietf-6man-resilient-rs@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, 22 Jan 2014 19:55:36 -0000 --001a11335cfc03911d04f0948264 Content-Type: text/plain; charset=UTF-8 [Resending with hopefully correct author mailing list] On Wed, Jan 22, 2014 at 11:46 AM, Lorenzo Colitti wrote: > On Mon, Oct 21, 2013 at 4:38 PM, wrote: > >> When an interface on a host is initialized, the host transmits Router >> Solicitations in order to minimize the amount of time it needs to >> wait until the next unsolicited multicast Router Advertisement is >> received. In certain scenarios, these router solicitations >> transmitted by the host might be lost. This document specifies a >> mechanism for hosts to cope with the loss of the initial Router >> Solicitations. 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. >> > > Authors, > > One comment here. > > If the intent is that we should be able to run networks that do not send > periodic RAs at all, then this document will need to require that hosts > send router solicitations when their RAs (or whatever is in the RA > contents, including lifetimes of PIOs, RIOs, RDNSS options, etc.) are about > to expire - otherwise the hosts will lose connectivity. > > This may be difficult to specify correctly. Specifically, it may be hard > to distinguish something that is being deprecated by the network (e.g., an > RA whose lifetime is counting down because it comes from a PD) from an RA > that is about to expire. > > If the intent is not that we should be able to run networks without > periodic RAs, then at least the text in 2b needs to change. > > Cheers, > Lorenzo > --001a11335cfc03911d04f0948264 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[Resending with hopefully correct author mailing list]


On Wed, Jan= 22, 2014 at 11:46 AM, Lorenzo Colitti <lorenzo@google.com>= wrote:
=
On Mon, Oct 21, 2013 at 4:38 P= M, <internet-drafts@ietf.org> wrote:
=C2=A0 =C2=A0When an interface on a host is = initialized, the host transmits Router
=C2=A0 =C2=A0Solicitations in order to minimize the amount of time it needs= to
=C2=A0 =C2=A0wait until the next unsolicited multicast Router Advertisement= is
=C2=A0 =C2=A0received. =C2=A0In certain scenarios, these router solicitatio= ns
=C2=A0 =C2=A0transmitted by the host might be lost. =C2=A0This document spe= cifies a
=C2=A0 =C2=A0mechanism for hosts to cope with the loss of the initial Route= r
=C2=A0 =C2=A0Solicitations. =C2=A0Furthermore, on some links, unsolicited m= ulticast
=C2=A0 =C2=A0Router Advertisements are never sent and the mechanism in this=
=C2=A0 =C2=A0document is intended to work even in such scenarios.

Authors,

One comm= ent here.

If the intent is that we should be able = to run networks that do not send periodic RAs at all, then this document wi= ll need to require that hosts send router solicitations when their RAs (or = whatever is in the RA contents, including lifetimes of PIOs, RIOs, RDNSS op= tions, etc.) are about to expire - otherwise the hosts will lose connectivi= ty.

This may be difficult to specify correctly. Speci= fically, it may be hard to distinguish something that is being deprecated b= y the network (e.g., an RA whose lifetime is counting down because it comes= from a PD) from an RA that is about to expire.

If the intent is not that we should be able to run netw= orks without periodic RAs, then at least the text in 2b needs to change.

Cheers,
Lorenzo

--001a11335cfc03911d04f0948264-- From rdroms.ietf@gmail.com Wed Jan 22 12:05: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 25D461A037F for ; Wed, 22 Jan 2014 12:05:45 -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 3yqRa7a6UG5a for ; Wed, 22 Jan 2014 12:05:43 -0800 (PST) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 908661A02D5 for ; Wed, 22 Jan 2014 12:05:43 -0800 (PST) Received: by mail-pd0-f177.google.com with SMTP id x10so809350pdj.22 for ; Wed, 22 Jan 2014 12:05: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=s0q2H6VODfW5iJcDBv4mgMP+SnHODPasSDTCnKNWaCQ=; b=t/Ig0mcUfJfuqtpSDN8OjxHFCFhRTqV6WpF4Ol7HiFHXCkPVs0kh41qnPjqcO5yWcT nz45/Marz7GPyatGeQ1falVxh2ufqKP3kHS2ThbFSaBKgI+PSjWgocLSShTlkI+6Xd3T r7fiytl3YYYDxeyQBz9EDs7d/SkMI5dBICSuIojYsPx2dPFXiOtjpfO4YpVLQdTrfW3G 9y+z120BoxEyrGAapctpbmxrnc1GIeDoF9eZk2EdVbDfoXF4LWhdv/pI9FFr5/qHz4It Zlx/a5VB0uOhNX/3xxTIUtEgO4bP3NwsFyipWyCHLHW/nxkokGmDm4UBzje/ivUL4ux/ v6lg== X-Received: by 10.68.168.162 with SMTP id zx2mr3733606pbb.74.1390421143104; Wed, 22 Jan 2014 12:05:43 -0800 (PST) Received: from [10.155.120.123] (128-107-239-235.cisco.com. [128.107.239.235]) by mx.google.com with ESMTPSA id q7sm26776578pbc.20.2014.01.22.12.05.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jan 2014 12:05:41 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt From: Ralph Droms In-Reply-To: Date: Wed, 22 Jan 2014 12:05:39 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6299FD64-01A9-4F19-B271-9891AFCA3269@gmail.com> References: <20131021233827.32495.34424.idtracker@ietfa.amsl.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1510) Cc: draft-ietf-6man-resilient-rs@tools.ietf.org, IETF IPv6 Mailing 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: Wed, 22 Jan 2014 20:05:45 -0000 On Jan 22, 2014, at 11:55 AM 1/22/14, Lorenzo Colitti = wrote: > [Resending with hopefully correct author mailing list] >=20 >=20 > On Wed, Jan 22, 2014 at 11:46 AM, Lorenzo Colitti = wrote: > On Mon, Oct 21, 2013 at 4:38 PM, wrote: > When an interface on a host is initialized, the host transmits = Router > Solicitations in order to minimize the amount of time it needs to > wait until the next unsolicited multicast Router Advertisement is > received. In certain scenarios, these router solicitations > transmitted by the host might be lost. This document specifies a > mechanism for hosts to cope with the loss of the initial Router > Solicitations. 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. >=20 > Authors, >=20 > One comment here. >=20 > If the intent is that we should be able to run networks that do not = send periodic RAs at all, then this document will need to require that = hosts send router solicitations when their RAs (or whatever is in the RA = contents, including lifetimes of PIOs, RIOs, RDNSS options, etc.) are = about to expire - otherwise the hosts will lose connectivity. I think it's worse than that. A host on a multicast-capable link on which "unsolicited multicast = Router Advertisements are never sent" will have to use the same = transmission behavior as a host on a non-multicast-capable link, so that = the host can learn of changes in the link prefixes in a timely fashion. Furthermore, a host on a multicast-capable link won't know if multicast = RAs are being sent on the link, so all hosts will have to send periodic = RSs. - Ralph >=20 > This may be difficult to specify correctly. Specifically, it may be = hard to distinguish something that is being deprecated by the network = (e.g., an RA whose lifetime is counting down because it comes from a PD) = from an RA that is about to expire. >=20 > If the intent is not that we should be able to run networks without = periodic RAs, then at least the text in 2b needs to change. >=20 > Cheers, > Lorenzo >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From otroan@employees.org Wed Jan 22 12:15: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 6BE6C1A01B6 for ; Wed, 22 Jan 2014 12:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 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] 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 Gof-Duppfwko for ; Wed, 22 Jan 2014 12:15:35 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFFA1A0149 for ; Wed, 22 Jan 2014 12:15:33 -0800 (PST) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 42710608A; Wed, 22 Jan 2014 12:15:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=selector1; bh=KxpXvbRMef9vhnN1CeZFN CBblmk=; b=TdP3UBzkAfjREV1SIonizkxro4ZpEmnW/+WZJ6SkOiPT5nScYRcGT TGE562RzJk5UtG8DXtNYCTHcKVfHQCVnvIFU6s1L6qyTAqNpKzkT7fDzx27zHvKA fYE4D10/sM2p6Fb5wAyurbYid4gphYRI6mhAAP9eJ//5Ssh/sVYWg4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; q=dns; s=selector1; b=QoGVuiYzodw/z+q uD+lCAL6J7BsgpYUi8Z7SAFxDRudTlGw4ucu1wky3UbNrHTe3SBViYr6Q1i5Rt4D 2zyHYp5hNqVnakb4npx+YT1UgxbHMD4fmINnFKWOeQqWbo7bfJCLaFiFrhm7reKQ /ju/5MpZG7Xq+yG1pamyp5g5DO5M= Received: from dhcp-10-61-101-124.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 16A086098; Wed, 22 Jan 2014 12:15:29 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_DE0E4609-A0B2-4377-B3FD-4E996397C01F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt From: Ole Troan In-Reply-To: <6299FD64-01A9-4F19-B271-9891AFCA3269@gmail.com> Date: Wed, 22 Jan 2014 21:15:26 +0100 Message-Id: <7AB1FAB9-6E17-4F1C-A8F0-784843FAA51B@employees.org> References: <20131021233827.32495.34424.idtracker@ietfa.amsl.com> <6299FD64-01A9-4F19-B271-9891AFCA3269@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1827) Cc: draft-ietf-6man-resilient-rs@tools.ietf.org, 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 20:15:37 -0000 --Apple-Mail=_DE0E4609-A0B2-4377-B3FD-4E996397C01F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> When an interface on a host is initialized, the host transmits = Router >> Solicitations in order to minimize the amount of time it needs to >> wait until the next unsolicited multicast Router Advertisement is >> received. In certain scenarios, these router solicitations >> transmitted by the host might be lost. This document specifies a >> mechanism for hosts to cope with the loss of the initial Router >> Solicitations. 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. >>=20 >> Authors, >>=20 >> One comment here. >>=20 >> If the intent is that we should be able to run networks that do not = send periodic RAs at all, then this document will need to require that = hosts send router solicitations when their RAs (or whatever is in the RA = contents, including lifetimes of PIOs, RIOs, RDNSS options, etc.) are = about to expire - otherwise the hosts will lose connectivity. >=20 > I think it's worse than that. >=20 > A host on a multicast-capable link on which "unsolicited multicast = Router Advertisements are never sent" will have to use the same = transmission behavior as a host on a non-multicast-capable link, so that = the host can learn of changes in the link prefixes in a timely fashion. >=20 > Furthermore, a host on a multicast-capable link won't know if = multicast RAs are being sent on the link, so all hosts will have to send = periodic RSs. for periodic RAs Router Lifetime / RtrAdvInterval >=3D 3 to ensure that = the mechanism works even when a couple of multicast messages are lost. if it is specified that the periodic RS is sent only after 2/3s of the = router lifetime has passed, then either the host would have received the = multicast advertisement, and dropped sending the periodic RS, or it lost = the multicast messages, and would be best off sending the RS anyway, or = it was on a link-type that didn't send periodic RAs. cheers, Ole --Apple-Mail=_DE0E4609-A0B2-4377-B3FD-4E996397C01F 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 iQEcBAEBCgAGBQJS4CbeAAoJEFuJXizso86gudAH/1s3JO4ZcWlNuGBRYrQGON5N xfOraQkxYOzewmyq2XeKt4eajKHFZrmOXXJvyPgycIJMHNNZ5CzXQDyg3oZdTcbu lQiMbpxLmdIi3FUv9pEcvOwziyahbOrI59dlLkasbH7yt1e7PAjw2tj6XzjNW06y /rzrBHEmSF7EQuWWNbYE6CurEPf+/uyZu3Nzi6MxCO5L3p532xXwyEEpxPB2WKNe N5canE0GnntHxMhBF+79GiChv+3jDg8DUcTXuWuFIsl4bTOWcER/iR8qXmA+4ZI3 jCWqrQpMlFkZ6pdzF0xqa8iFBoqjHaIMaR3o8JWycVU8B4xa7bW2eDa0bXBK2yA= =Z8ju -----END PGP SIGNATURE----- --Apple-Mail=_DE0E4609-A0B2-4377-B3FD-4E996397C01F-- From rdroms.ietf@gmail.com Wed Jan 22 12:20: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 45BD01A047A for ; Wed, 22 Jan 2014 12:20:03 -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 i7o4c6rkquYP for ; Wed, 22 Jan 2014 12:20:01 -0800 (PST) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B331E1A03E7 for ; Wed, 22 Jan 2014 12:19:53 -0800 (PST) Received: by mail-yh0-f43.google.com with SMTP id z20so349370yhz.30 for ; Wed, 22 Jan 2014 12:19:53 -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=vI2pwCqN41keIPs9zxhQUJBAmEobRrKtEAFB3luz/TA=; b=iPTdo5a+Rh5XRfvnk41G0QEL7YjswBdqkc3fkiop/z9QipGg297oy1romqaRbv515f K01nZaWb4OSooh1NvokpHGEwP/sL9Dsv6UoZcV2RbHxBWl1MCeHLEZhivZur69VQ0PNC HAUrn/7vZN4qyDeoaBHCRNPC3NZy8stL4SRtbTDkuao39fdrGmbDM9zwEvXWRdMsHMh/ PB1t34gYHoz7yNQqyzydYakLkkh6umdaCnryws1T7CLgiOnIyP8rVgsgRsT0pk4hLUWx 41NK3BjC99Q7TwyRx5lhJBrJ8qnGL/ulDKcHyb6q+yOpcX4tStPWYVeQ5ZX3S1rM0Xho 8hng== X-Received: by 10.236.127.39 with SMTP id c27mr3679234yhi.120.1390421993045; Wed, 22 Jan 2014 12:19:53 -0800 (PST) Received: from ?IPv6:2001:420:285:1004:d849:2a2d:7919:cf85? ([2001:420:285:1004:d849:2a2d:7919:cf85]) by mx.google.com with ESMTPSA id s93sm8591859yhp.1.2014.01.22.12.19.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jan 2014 12:19:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt From: Ralph Droms In-Reply-To: <7AB1FAB9-6E17-4F1C-A8F0-784843FAA51B@employees.org> Date: Wed, 22 Jan 2014 12:19:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <007C5C8C-5837-48B7-8641-20B85DF818FF@gmail.com> References: <20131021233827.32495.34424.idtracker@ietfa.amsl.com> <6299FD64-01A9-4F19-B271-9891AFCA3269@gmail.com> <7AB1FAB9-6E17-4F1C-A8F0-784843FAA51B@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1510) Cc: draft-ietf-6man-resilient-rs@tools.ietf.org, 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 20:20:03 -0000 On Jan 22, 2014, at 12:15 PM 1/22/14, Ole Troan = wrote: >>> When an interface on a host is initialized, the host transmits = Router >>> Solicitations in order to minimize the amount of time it needs to >>> wait until the next unsolicited multicast Router Advertisement is >>> received. In certain scenarios, these router solicitations >>> transmitted by the host might be lost. This document specifies a >>> mechanism for hosts to cope with the loss of the initial Router >>> Solicitations. 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. >>>=20 >>> Authors, >>>=20 >>> One comment here. >>>=20 >>> If the intent is that we should be able to run networks that do not = send periodic RAs at all, then this document will need to require that = hosts send router solicitations when their RAs (or whatever is in the RA = contents, including lifetimes of PIOs, RIOs, RDNSS options, etc.) are = about to expire - otherwise the hosts will lose connectivity. >>=20 >> I think it's worse than that. >>=20 >> A host on a multicast-capable link on which "unsolicited multicast = Router Advertisements are never sent" will have to use the same = transmission behavior as a host on a non-multicast-capable link, so that = the host can learn of changes in the link prefixes in a timely fashion. >>=20 >> Furthermore, a host on a multicast-capable link won't know if = multicast RAs are being sent on the link, so all hosts will have to send = periodic RSs. >=20 > for periodic RAs Router Lifetime / RtrAdvInterval >=3D 3 to ensure = that the mechanism works even when a couple of multicast messages are = lost. Agreed. > if it is specified that the periodic RS is sent only after 2/3s of the = router lifetime has passed, then either the host would have received the = multicast advertisement, and dropped sending the periodic RS, or it lost = the multicast messages, and would be best off sending the RS anyway, or = it was on a link-type that didn't send periodic RAs. OK ... but the host will not learn about new prefixes assigned to the = link in a timely fashion, which is (I infer) the motivation for this = text: On non-multicast links, the hosts following this specification MUST continue retransmitting the RSs even after an RA that results in a default route is received. - Ralph >=20 > cheers, > Ole >=20 >=20 From brian@innovationslab.net Wed Jan 22 12:24: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 F16211A0158; Wed, 22 Jan 2014 12:24:35 -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 DAqlBtIrmNEu; Wed, 22 Jan 2014 12:24:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 831671A012E; Wed, 22 Jan 2014 12:24:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Brian Haberman" To: The IESG Subject: Brian Haberman's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS) X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140122202434.30069.4084.idtracker@ietfa.amsl.com> Date: Wed, 22 Jan 2014 12:24:34 -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: Wed, 22 Jan 2014 20:24:36 -0000 Brian Haberman has entered the following ballot position for draft-ietf-6man-stable-privacy-addresses-16: Discuss 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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I am taking the somewhat curious route of raising a DISCUSS on a document that I am shepherding. I will return to a Yes when these issues are resolved. Thomas Narten raised a good point that this document does not mention the work published in RFCs 4436 and 6059 (from the concluded DNA WG). Two of the points he raised are worth addressing in this document prior to publication. 1. If you have stable storage (and many devices do), it makes sense to just cache the addresses instead of regenerating them. DNA does this. Seems like that option should be allowed. (the current document suggests saving the number of DAD iterations in stable storage... why do that if you can just save the address itself?) 2. DNA also has recommendations for detecting when you (re)connect to a network you visited before. That is pretty much the same thing this spec needs to do in order to generate the same addresses when connecting to a previously visited network (i.e., the Network_ID paramater). For the wired case (i.e, no SSID), DNA suggests using the linklayer/linklocal address pair of routers to identify a link. This document might suggest doing the same thing. From otroan@employees.org Wed Jan 22 12:27: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 B36DE1A01D0 for ; Wed, 22 Jan 2014 12:27:36 -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, 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 nsfLm218-Rqa for ; Wed, 22 Jan 2014 12:27:35 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 476781A0132 for ; Wed, 22 Jan 2014 12:27:35 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFANco4FKQ/khL/2dsb2JhbABbgwy8a4EXFnSCJQEBAQMBeRALDjhXBogQCMNrF458B4MkgRQEkDuZf4MuOw X-IronPort-AV: E=Sophos;i="4.95,702,1384300800"; d="asc'?scan'208";a="4031113" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 22 Jan 2014 20:27:34 +0000 Received: from dhcp-10-61-101-124.cisco.com (dhcp-10-61-101-124.cisco.com [10.61.101.124]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0MKRWpj007893 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Jan 2014 20:27:33 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_18575BA3-DF62-4294-AD29-1CD17AA2B6D4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt From: Ole Troan In-Reply-To: <007C5C8C-5837-48B7-8641-20B85DF818FF@gmail.com> Date: Wed, 22 Jan 2014 21:27:32 +0100 Message-Id: <94B0A155-DC47-4C42-B18B-35C94CB09BDD@employees.org> References: <20131021233827.32495.34424.idtracker@ietfa.amsl.com> <6299FD64-01A9-4F19-B271-9891AFCA3269@gmail.com> <7AB1FAB9-6E17-4F1C-A8F0-784843FAA51B@employees.org> <007C5C8C-5837-48B7-8641-20B85DF818FF@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1827) Cc: draft-ietf-6man-resilient-rs@tools.ietf.org, 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 20:27:36 -0000 --Apple-Mail=_18575BA3-DF62-4294-AD29-1CD17AA2B6D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ralph, [...] >> if it is specified that the periodic RS is sent only after 2/3s of = the router lifetime has passed, then either the host would have received = the multicast advertisement, and dropped sending the periodic RS, or it = lost the multicast messages, and would be best off sending the RS = anyway, or it was on a link-type that didn't send periodic RAs. >=20 > OK ... but the host will not learn about new prefixes assigned to the = link in a timely fashion, which is (I infer) the motivation for this = text: >=20 > On non-multicast links, the hosts following this specification MUST > continue retransmitting the RSs even after an RA that results in a > default route is received. I'm not sure that 3600 seconds is timely fashion. ;-) I'm not quite sure why the reference to non-multicast links is there. (and I'm not sure we need to talk about it, if the only example is = ISATAP). ND doesn't really run over non-multicast links. I can recommend RFC2022. = ;-) cheers, Ole --Apple-Mail=_18575BA3-DF62-4294-AD29-1CD17AA2B6D4 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 iQEcBAEBCgAGBQJS4Cm0AAoJEFuJXizso86gtR4IAJ4EWSCv6JEKAf3uli2g3ins n0IvLgxUJF3jy+ZLREig0O3F69nzz9nyhIdQOz8jlyn2VvoCLi6xCG7t4h+uTGRL BgDfQEogeRlodqUygvjt0H5aQEaFiky9F6VHXZFHQ+Bwqpc7idqCigG29+dReUbl g8LJBirCyFtNeXJ4nsdzozsdGOXSa6PSKMWFPM8ZHm1CeU38+RZ5ljzfk4807WiT NmWC6hWB1+P3VK2TpGagZ+kRT5OWkyN+y0ww/KPrVN2cnOB6X9ZrJz+qLbVS/sdl I9b2Xzz0rXwKRJiWVhqMpLosssatwngQZZhcnOWcYuWcZSh8ICSMMTNAY4tJvVo= =Falh -----END PGP SIGNATURE----- --Apple-Mail=_18575BA3-DF62-4294-AD29-1CD17AA2B6D4-- From fgont@si6networks.com Wed Jan 22 12:49: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 E8D381A0158; Wed, 22 Jan 2014 12:49:05 -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 AdKlDfLyf9QV; Wed, 22 Jan 2014 12:49: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 B53121A01B3; Wed, 22 Jan 2014 12:49:03 -0800 (PST) Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W64jJ-0000rC-Sw; Wed, 22 Jan 2014 21:48:58 +0100 Message-ID: <52E02C0C.7080901@si6networks.com> Date: Wed, 22 Jan 2014 17:37:32 -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: Pete Resnick , The IESG Subject: Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT) References: <20140122192018.8692.82071.idtracker@ietfa.amsl.com> In-Reply-To: <20140122192018.8692.82071.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Wed, 22 Jan 2014 20:49:06 -0000 Hi, Pete, Thanks so much for your feedback! -- Please find my responses in-line... On 01/22/2014 04:20 PM, Pete Resnick wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > This is an algorithm to generate stable, private, and mostly unique > addresses. It does not affect interoperability at all if people choose a > different method. The short answer to this is what Bob has already responding: We currently require nodes to embed their hardware address in the IID when they do SLAAC. And every other specification to generate IIDs is also Std track. So we are being consistent. In addition, the document itself has requirements when it comes to things you MUST or SHOULD do... otherwise, the mechanism doesn't work as expected. All the above said, there are many documents from different areas where we have std track RFCs which "do not affect interoperability". e.g. TCP congestion control, TCPs initial RTO, etc. which, from your pov, should be informational? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Wed Jan 22 12:49: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 8E01E1A0214; Wed, 22 Jan 2014 12:49:49 -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 sqPijgsYoKx4; Wed, 22 Jan 2014 12:49:48 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id E2A261A0158; Wed, 22 Jan 2014 12:49:47 -0800 (PST) Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W64k5-0000rP-3F; Wed, 22 Jan 2014 21:49:45 +0100 Message-ID: <52E02EAD.1050009@si6networks.com> Date: Wed, 22 Jan 2014 17:48:45 -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 Haberman , The IESG Subject: Re: Brian Haberman's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS) References: <20140122202434.30069.4084.idtracker@ietfa.amsl.com> In-Reply-To: <20140122202434.30069.4084.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Wed, 22 Jan 2014 20:49:49 -0000 On 01/22/2014 05:24 PM, Brian Haberman wrote: > > I am taking the somewhat curious route of raising a DISCUSS on a document > that I am shepherding. I will return to a Yes when these issues are > resolved. Thomas Narten raised a good point that this document does not > mention the work published in RFCs 4436 and 6059 (from the concluded DNA > WG). Two of the points he raised are worth addressing in this document > prior to publication. > > 1. If you have stable storage (and many devices do), it makes sense to > just cache the addresses instead of > regenerating them. 1) Recording the addresses a node has visited during its lifetime would somehow be ironic for a document aiming at privacy. Just get the document compromised, and you get a list of where the node has been since it was first installed. 2) Recording the addresses seems like a waste of resources. How many networks you connect to only once in your lifetime? > DNA does this. Seems like that option should be > allowed. (the current document suggests saving the number of DAD > iterations in stable storage... why do that if you can just save the > address itself?) The current document allows that to happen for cases where you find a colission -- which would be close to nil, given that subnets are /64 and the IIDs are essentially random. That said, as an author, I don't expect implementations to record the dad counter ever, even in the presence of collisions. I'd argue that that paragraph is there with this rationale "if you're picky and you're going to argue that this spec doesn't guarantee a stable IID, you can do this if you want". > 2. DNA also has recommendations for detecting when you (re)connect to a > network you visited before. That is pretty much the same thing this spec > needs to do in order to generate the same addresses when connecting to a > previously visited network (i.e., the Network_ID paramater). For the > wired case (i.e, no SSID), DNA suggests using the linklayer/linklocal > address pair of routers to identify a link. This document might suggest > doing the same thing. IMHO, using the linklayer/linklocal address of the router is not a good idea. Thing about a replaced NIC, or a backup router that kicks in in the event of failuer of the main one. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Wed Jan 22 13:01: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 F1C971A0158 for ; Wed, 22 Jan 2014 13:01:57 -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 RMGJgVujwuY7 for ; Wed, 22 Jan 2014 13:01:57 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id E710C1A012E for ; Wed, 22 Jan 2014 13:01:56 -0800 (PST) Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W64vo-0001GX-1F; Wed, 22 Jan 2014 22:01:52 +0100 Message-ID: <52E03111.7090800@si6networks.com> Date: Wed, 22 Jan 2014 17:58:57 -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 , ipv6@ietf.org Subject: Re: revisit protocol constants ?? 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: Wed, 22 Jan 2014 21:01:58 -0000 Thomas, On 01/22/2014 03:55 PM, Thomas Narten wrote: > Here is an excerpt from my review of the stable addresses document. I > wonder if we should rethink some of the protocol constants we are > defining. The world is becoming more diverse and it seems that a "one > size fits all" notion for some protocol constants is making less and > less sense. > >> Finally, I want to raise a generic issue that applies to this >> document, but really is a general problem. The document adds a random >> delay between 0 and IDGEN_DELAY in order to avoid lock-step >> behavior. While that is a good thing, Using IDGEN_DELAY of 1 second is >> pretty long for some network technologies (think data center with 10G >> or higher interfaces). I wonder if we should stop using constants that >> are fixed and make them more dependent on actual network >> technology. E.g., 1 second seems OK for WiFi, but not for 10G. I'd say that I generally agree with your point of view... But the IDGEN_DELAY is really a bad example. We're talking about waiting for *at most* 1 second (say, 0.5 seconds in the general case) and *only* when two 64-bit random numbers collide. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From presnick@qti.qualcomm.com Wed Jan 22 13:03: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 B471C1A0360; Wed, 22 Jan 2014 13:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 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] 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 lMZZHKC0cpVZ; Wed, 22 Jan 2014 13:03:43 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 095061A034D; Wed, 22 Jan 2014 13:03:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1390424623; x=1421960623; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=yb5l9sGoG5QYIyjYg8O57YfvI+J5WAo/4eyF1pfDodk=; b=a2w8DmTeJARZF/Ql3+Ci0KXoWfDpQhaZCbI/Jr8273y7Q5czhh4Fs9zK YxdxpjAUxh1rsQSkh6G8bMuWKCGvtB0goUA0UULGIWgeyH+ze8quBTjQp HhRm8NiJnM9uF8yArB/oYcWtPwx8GY8ZC0spEV/bSx6mU/5BXlQSq82K1 8=; X-IronPort-AV: E=McAfee;i="5400,1158,7326"; a="58416828" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth01.qualcomm.com with ESMTP; 22 Jan 2014 13:03:43 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,7326"; a="606515300" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 22 Jan 2014 13:03:42 -0800 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Jan 2014 13:03:42 -0800 Message-ID: <52E0322C.1000301@qti.qualcomm.com> Date: Wed, 22 Jan 2014 15:03:40 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Fernando Gont Subject: Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT) References: <20140122192018.8692.82071.idtracker@ietfa.amsl.com> <52E02C0C.7080901@si6networks.com> In-Reply-To: <52E02C0C.7080901@si6networks.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, The IESG , 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, 22 Jan 2014 21:03:44 -0000 On 1/22/14 2:37 PM, Fernando Gont wrote: > Hi, Pete, > > Thanks so much for your feedback! -- Please find my responses in-line... > > On 01/22/2014 04:20 PM, Pete Resnick wrote: > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> This is an algorithm to generate stable, private, and mostly unique >> addresses. It does not affect interoperability at all if people choose a >> different method. >> > The short answer to this is what Bob has already responding: > > We currently require nodes to embed their hardware address in the IID > when they do SLAAC. And every other specification to generate IIDs is > also Std track. So we are being consistent. > As you might have guessed, consistently doing the incorrect thing isn't terribly convincing to me. > In addition, the document itself has requirements when it comes to > things you MUST or SHOULD do... otherwise, the mechanism doesn't work as > expected. > Section 6 of 2119 is a good read. > All the above said, there are many documents from different areas where > we have std track RFCs which "do not affect interoperability". e.g. TCP > congestion control, TCPs initial RTO, etc. which, from your pov, should > be informational? > I'm happy to extend "interoperability" to mean "an individual host won't screw up the net for everybody else, even if it's not directly communicating with it." That's why I think it's reasonable to include congestion control, some security mechanisms, etc. But if the only reason I'm doing something a particular way is for *my* privacy, or *my* convenience, or to accomplish a local task on my system, that doesn't need standardized documentation requiring (eventually) two independent interoperable implementations. Perhaps 6410 has simply done away with the whole notion of what it is to standardize things. Maybe I'm in the rough. But I think local configuration options and ways to do things that are not about interoperably communicating across the Internet have no place in the standards track. Otherwise, we're just a publication house for interesting Internet technologies. I'm not interested in being that. So I stand by my claim: This should not be on the standards track. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From brian@innovationslab.net Wed Jan 22 13:44: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 AB7B31A0476; Wed, 22 Jan 2014 13:44:23 -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 TGzghl4BWGW0; Wed, 22 Jan 2014 13:44:21 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id CE96D1A0451; Wed, 22 Jan 2014 13:44:21 -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 83FBE880F3; Wed, 22 Jan 2014 13:44:21 -0800 (PST) Received: from clemson.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 E1228130003; Wed, 22 Jan 2014 13:44:20 -0800 (PST) Message-ID: <52E03BAD.5050306@innovationslab.net> Date: Wed, 22 Jan 2014 16:44:13 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Fernando Gont , The IESG Subject: Re: Brian Haberman's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS) References: <20140122202434.30069.4084.idtracker@ietfa.amsl.com> <52E02EAD.1050009@si6networks.com> In-Reply-To: <52E02EAD.1050009@si6networks.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="afronNclKUS71qfWC7l9h9pLWqWiknGl2" 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: Wed, 22 Jan 2014 21:44:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --afronNclKUS71qfWC7l9h9pLWqWiknGl2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/22/14 3:48 PM, Fernando Gont wrote: > On 01/22/2014 05:24 PM, Brian Haberman wrote: >> >> I am taking the somewhat curious route of raising a DISCUSS on a docum= ent >> that I am shepherding. I will return to a Yes when these issues are >> resolved. Thomas Narten raised a good point that this document does n= ot >> mention the work published in RFCs 4436 and 6059 (from the concluded D= NA >> WG). Two of the points he raised are worth addressing in this documen= t >> prior to publication. >> >> 1. If you have stable storage (and many devices do), it makes sense to= >> just cache the addresses instead of >> regenerating them. >=20 > 1) Recording the addresses a node has visited during its lifetime would= > somehow be ironic for a document aiming at privacy. Just get the > document compromised, and you get a list of where the node has been > since it was first installed. I think I can get a list of where a device has been from any number of places. So, I don't buy that argument at all. >=20 > 2) Recording the addresses seems like a waste of resources. How many > networks you connect to only once in your lifetime? >=20 Uh, storing 16 (or so) bytes per location is rather low-cost. >=20 >=20 >> DNA does this. Seems like that option should be >> allowed. (the current document suggests saving the number of DAD >> iterations in stable storage... why do that if you can just save the >> address itself?) >=20 > The current document allows that to happen for cases where you find a > colission -- which would be close to nil, given that subnets are /64 an= d > the IIDs are essentially random. >=20 > That said, as an author, I don't expect implementations to record the > dad counter ever, even in the presence of collisions. I'd argue that > that paragraph is there with this rationale "if you're picky and you're= > going to argue that this spec doesn't guarantee a stable IID, you can d= o > this if you want". >=20 Now you are getting into specifying implementation details and that is not good. All this point is making is that there are a variety of ways of getting this behavior and DNA provided guidance on one way to do that. The simple solution is to refer to those RFCs (informatively) and point out that they describe one way to track which addresses are associated with particular networks. This has the benefit of not forcing re-calculation of the hash on every (re-)connect. >=20 >=20 >> 2. DNA also has recommendations for detecting when you (re)connect to = a >> network you visited before. That is pretty much the same thing this sp= ec >> needs to do in order to generate the same addresses when connecting to= a >> previously visited network (i.e., the Network_ID paramater). For the >> wired case (i.e, no SSID), DNA suggests using the linklayer/linklocal >> address pair of routers to identify a link. This document might sugges= t >> doing the same thing. >=20 > IMHO, using the linklayer/linklocal address of the router is not a good= > idea. Thing about a replaced NIC, or a backup router that kicks in in > the event of failuer of the main one. We have had this discussion before. The Network_ID variable really should be used to whatever extent possible. For a wired network, the DNA approach of caching a router's link-local address seems like a good approach. Yes, it will not work if the router's interface changes, but that should be rather infrequent. Regards, Brian --afronNclKUS71qfWC7l9h9pLWqWiknGl2 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 iQEcBAEBCgAGBQJS4DuzAAoJEBOZRqCi7goqzscH/icELTMG1VrG0B3xntZLN9sg ymvByM4A2fFmV+EShSU3agQ1uxS3gJhsHvoyRtwZsq1MnjQuiFtGjy66JWymkZ4i Gfw/xTB4i28ic9NcOSeq0cGBW/TQLrieTp7638ChEd4H523pt43o0PofoGh2BXb0 q5g+XEWv/UJVnkKSpnNrqxAOwXRH9aiwlGtLBBKCdLqANHARlQXsD1WOtWXMYQM2 QhMP56vWCogGf5feMegIMd52hoaPZy4kGEbQ+ayJHZ8wLgJV/uZeqeShuwoDnSPi 6sWf6+G7U5kPebNgkfSaCoGghqerqqZ18Iw8fy1wKuLmayvawLWD5lMqr3gebFQ= =5NPA -----END PGP SIGNATURE----- --afronNclKUS71qfWC7l9h9pLWqWiknGl2-- From nordmark@acm.org Wed Jan 22 13:44: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 410C81A04A1 for ; Wed, 22 Jan 2014 13:44:27 -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 uOXMg940o0ga for ; Wed, 22 Jan 2014 13:44:25 -0800 (PST) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id D46741A0494 for ; Wed, 22 Jan 2014 13:44:25 -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 s0MLiKb9013860 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 22 Jan 2014 13:44:20 -0800 Message-ID: <52E03BB4.8040309@acm.org> Date: Wed, 22 Jan 2014 13:44:20 -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: Lorenzo Colitti , Erik Nordmark 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=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;CgjXWa6D4xG38MecJ1f4WQ== M;BnjyWa6D4xG38MecJ1f4WQ== Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG , =?UTF-8?B?QW5kcmV3IPCfkb0gWW91cnRjaGVua28=?= 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:44:27 -0000 On 1/21/14 12:34 PM, Lorenzo Colitti wrote: > 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. Lorenzo, Whether you call it "efficiency" or "robustness" doesn't make much difference from a technical or a process perspective. The approach you advocate is insufficient to ensure better robustness for at least two reasons: - the lifetime(s) of the prefixes are independent of the lifetimes of the default routers. Hence in this approach a host can have default routers but no prefixes. - the reachability state in the NCEs is independent of the default router list - per RFC 4861 the router stays in the default router list even if it is unreachable. Thus your last router might be unreachable but with remaining lifetime - it was the next-to-last router in the list that was reachable. Solving those without risking hosts sending lots of RSs during failure events or resulting in a steady state of RSs from hosts seems tricky. > FWIW I don't have a problem with an opt-in update to 4861. I even > think efficient-nd is the way to go because it reduces overall ND > multicast traffic and not just your narrow focus on mobile phone > battery life. > > > The tradeoff is that efficient ND adds more state to the network about > host addresses and changes a pretty core part of the IPv6 specs. I think > that if we can reduce the battery impact of multicast traffic, we will > have fixed most of the problem without doing either of those, and to my > mind, that's a much better tradeoff. Changing from periodic RAs to (effectively) periodic RSs as you propose would change RFC 4861 is a very fundamental way. It may or may not be the right thing to do for the future, but I think that requires a bit more work then forcing some edits into a document which has almost completed the WG process. I think resilient-rs has significant benefits in its current form and scope. Regards, Erik From otroan@employees.org Wed Jan 22 13:52: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 853FC1A0445 for ; Wed, 22 Jan 2014 13:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 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] 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 PR62ojXN7Tgs for ; Wed, 22 Jan 2014 13:52:41 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id E16BD1A02F0 for ; Wed, 22 Jan 2014 13:52:40 -0800 (PST) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 2C19E5FF3; Wed, 22 Jan 2014 13:52:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=selector1; bh=h3ZxLjBv8J3RBH9TwPIuD MW7Ju0=; b=d095koerL+9rAf45u74+w/kKZJmRxLF0+dV1JJKXWhm33YNzey/d7 iDd9OUPGEweEAlX9bS18T2zq+XeV4ITheAW1MjfLzM0mzkPGrPTIb8HXQZ7XeWhl xdX6I13SLpXMi5Z7RV9L+oVRUERjtPzqII8PljoUvgO+mypgYVISRw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; q=dns; s=selector1; b=MnnP3MgTdNVAGdE j34e0Y0sWQUd8xFx/ubsHUSrq1UBueQLIZtUyEB6hV9rAetl6eK/yVWwn0X91wk3 Q/PwkZMNVzW6HqD0BuxbpOnjbd+Ju/huoppepkA/IjDReakIdHNVre2C9X1ssnwm cCymWEISH5GWVPBoR90YVNcZ1Eeo= Received: from dhcp-10-61-97-137.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 EEEF55FC9; Wed, 22 Jan 2014 13:52:36 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_C8F506DF-A2EE-41C9-BD05-60481F2A1D87"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Reducing the battery impact of ND From: Ole Troan In-Reply-To: <52E03C9D.7010605@sonic.net> Date: Wed, 22 Jan 2014 22:52:33 +0100 Message-Id: <6D5AD847-30B2-467A-87B6-31C089C9380F@employees.org> References: <52D96663.6060005@sonic.net> <52DA0ABA.8030903@acm.org> <52E03C9D.7010605@sonic.net> To: Erik Nordmark X-Mailer: Apple Mail (2.1827) Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Erik Nordmark , 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: Wed, 22 Jan 2014 21:52:42 -0000 --Apple-Mail=_C8F506DF-A2EE-41C9-BD05-60481F2A1D87 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Erik, >>> One of your "yes please" below is a change to ND - Andrew's b) = about >>> restarting RS would require a (small) standards update. >>>=20 >>>=20 >>> We should try to get that into draft-6man-resilient-rs. >>>=20 >>> 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. >>=20 >> 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." >=20 > I think that text can be read in different ways. >=20 > 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. >=20 > Another way is that the document intended to get rid of the need for = unsolicited multicast RAs. >=20 > Based on the title, name, and content of the document, my conclusion = is that the first reading is much more accurate. the first reading implies that the host looses connectivity after router = lifetime seconds. "never sent" doesn't leave much room for interpretation. >>> 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. >>=20 >> 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? >=20 > It makes sense having the document be clear on its scope, so some = clarification is in order. cheers, Ole --Apple-Mail=_C8F506DF-A2EE-41C9-BD05-60481F2A1D87 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 iQEaBAEBCgAGBQJS4D2hAAoJEFuJXizso86g2vwH8J3pLHNgCFJESOrdX1t7byi5 0ETGAMvkWu7aLdq26GFABaLYn6/N2tl+6KsE7lqqUkHT8mrDmkp4O2Y2iNiCgu9K 49Wqx7qSD2Q0LjuNYvbh4dzMpyHJXwO3U9n2juDFMky1v4MNet1J57uUcRAbZY+H WBTnWoB+n+JQSRwqDGxhmOt20fyuGz4BWcuPvwS+203t1YPXC0YY60dBAMd3k96c WVtpQXju4ImNfoOuNJ41/1YvxahCzrxriXBS0BAqM2zCsqpqP1jA1lpmPo7vikpL d1jiY7IQArtB1SJ/IvWHWENqPIGwdtgn2JmUwhh7jZN6p0aBvNspjLaxny// =tlWm -----END PGP SIGNATURE----- --Apple-Mail=_C8F506DF-A2EE-41C9-BD05-60481F2A1D87-- From fernando@gont.com.ar Wed Jan 22 13:53: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 51B571A04A0; Wed, 22 Jan 2014 13:53:29 -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 v_ag3qjpLGOy; Wed, 22 Jan 2014 13:53:27 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2811A0455; Wed, 22 Jan 2014 13:53:27 -0800 (PST) Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W65jd-0002Wt-48; Wed, 22 Jan 2014 22:53:21 +0100 Message-ID: <52E03DCB.4060101@gont.com.ar> Date: Wed, 22 Jan 2014 18:53:15 -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: Pete Resnick , Fernando Gont Subject: Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT) References: <20140122192018.8692.82071.idtracker@ietfa.amsl.com> <52E02C0C.7080901@si6networks.com> <52E0322C.1000301@qti.qualcomm.com> In-Reply-To: <52E0322C.1000301@qti.qualcomm.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, The IESG , 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, 22 Jan 2014 21:53:29 -0000 On 01/22/2014 06:03 PM, Pete Resnick wrote: >>> This is an algorithm to generate stable, private, and mostly unique >>> addresses. It does not affect interoperability at all if people choose a >>> different method. >>> >> The short answer to this is what Bob has already responding: >> >> We currently require nodes to embed their hardware address in the IID >> when they do SLAAC. And every other specification to generate IIDs is >> also Std track. So we are being consistent. > > As you might have guessed, consistently doing the incorrect thing isn't > terribly convincing to me. If how you select an IID is not std track, prepare for lazy implementations to set the IID to "1" and hence for collisions to become common. At that point that becomes an interoperability problem. And, a folk working on a v6 stack needs to implement *something*. When he gets to the point of generating an IID, there's something he has to follow. This document is one way to do it. With specific goals in mind. And specific requirements if you mean to meet does goals. That looks std track to me. >> All the above said, there are many documents from different areas where >> we have std track RFCs which "do not affect interoperability". e.g. TCP >> congestion control, TCPs initial RTO, etc. which, from your pov, should >> be informational? > > I'm happy to extend "interoperability" to mean "an individual host won't > screw up the net for everybody else, even if it's not directly > communicating with it." That's not interoperability, but a different goal. At that point, you're doing your own thing rather than the Section 6 of RFC2119 you're quoting. > Perhaps 6410 has simply done away with the whole notion of what it is to > standardize things. Maybe I'm in the rough. But I think local > configuration options and ways to do things that are not about > interoperably communicating across the Internet have no place in the > standards track. If the "local policy" results in a high number of collisions, which subsequently result in a high number of retries, you might find that the local policy now has interoperability implications. It's entirely local policy if it the whole thing relies on your node. But when it comes to IIDs, they are required to be unique. And that's not "local" anymore (or not "local to the host", at least). 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 nordmark@acm.org Wed Jan 22 13:54: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 AC7791A0383 for ; Wed, 22 Jan 2014 13:54:34 -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 zMD44dICIdps for ; Wed, 22 Jan 2014 13:54:33 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 447B01A02F0 for ; Wed, 22 Jan 2014 13:54:33 -0800 (PST) Received: from [10.0.1.44] (184-23-158-201.dsl.dynamic.sonic.net [184.23.158.201]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s0MLsRF6004117 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 22 Jan 2014 13:54:28 -0800 Message-ID: <52E03E13.8080800@acm.org> Date: Wed, 22 Jan 2014 13:54:27 -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: Ralph Droms , Lorenzo Colitti 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> In-Reply-To: <6299FD64-01A9-4F19-B271-9891AFCA3269@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;SM7Bw6+D4xGUEvMsIE/FGg== M;/LDzw6+D4xGUEvMsIE/FGg== Cc: draft-ietf-6man-resilient-rs@tools.ietf.org, IETF IPv6 Mailing 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: Wed, 22 Jan 2014 21:54:34 -0000 On 1/22/14 12:05 PM, Ralph Droms wrote: > > On Jan 22, 2014, at 11:55 AM 1/22/14, Lorenzo Colitti wrote: > >> [Resending with hopefully correct author mailing list] >> >> >> On Wed, Jan 22, 2014 at 11:46 AM, Lorenzo Colitti wrote: >> On Mon, Oct 21, 2013 at 4:38 PM, wrote: >> When an interface on a host is initialized, the host transmits Router >> Solicitations in order to minimize the amount of time it needs to >> wait until the next unsolicited multicast Router Advertisement is >> received. In certain scenarios, these router solicitations >> transmitted by the host might be lost. This document specifies a >> mechanism for hosts to cope with the loss of the initial Router >> Solicitations. 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. >> >> Authors, >> >> One comment here. >> >> If the intent is that we should be able to run networks that do not send periodic RAs at all, then this document will need to require that hosts send router solicitations when their RAs (or whatever is in the RA contents, including lifetimes of PIOs, RIOs, RDNSS options, etc.) are about to expire - otherwise the hosts will lose connectivity. > > I think it's worse than that. > > A host on a multicast-capable link on which "unsolicited multicast Router Advertisements are never sent" will have to use the same transmission behavior as a host on a non-multicast-capable link, so that the host can learn of changes in the link prefixes in a timely fashion. > > Furthermore, a host on a multicast-capable link won't know if multicast RAs are being sent on the link, so all hosts will have to send periodic RSs. Even if you jump to a period RS from every host approach, there would still be operational questions on what timer to use, and whether there is a way for the operator to quickly introduce a new prefix (and retire an old prefix). With multicast RAs the operator can change the list of prefixes (to handle some problem) quite quickly. To accomplish the same thing without the multicast RA option would imply either - frequent periodic RSs from all the hosts, or - robustly tracking the set of hosts in the routers so that unicast RAs can be used for such changes. Regards, Erik > - Ralph > > >> >> This may be difficult to specify correctly. Specifically, it may be hard to distinguish something that is being deprecated by the network (e.g., an RA whose lifetime is counting down because it comes from a PD) from an RA that is about to expire. >> >> If the intent is not that we should be able to run networks without periodic RAs, then at least the text in 2b needs to change. >> >> Cheers, >> Lorenzo >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From otroan@employees.org Wed Jan 22 13:57: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 1FEAA1A0493 for ; Wed, 22 Jan 2014 13:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 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] 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 K7BVyUoFECsY for ; Wed, 22 Jan 2014 13:57:20 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC541A0487 for ; Wed, 22 Jan 2014 13:57:20 -0800 (PST) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id E47CA5FE0; Wed, 22 Jan 2014 13:57:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=selector1; bh=K3QoL/T875OFMaR/aRfdx TwqVaY=; b=Nv8IqQSe5jQlse8mlV5cVWoCnuWZudjenuiIqd/abMEK7tEKuGfMP iGdNkKTYdyd68pvd59x1cftwQnTOTxOpm67igxFrq4HoDzEsMbSERFnmJK04pQIX 5slRMALfH3UMUO3+PNHnnsyGWzbJkpCfnPTMDeWOxOLL/JdMkd55Tw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; q=dns; s=selector1; b=krKTmU2q45w8w12 /g7tzHdq3MJwGXk/gfWXbvN/YWH0lsZhAW200g88K1mgdG7JpuH4AoH/zeQAUEru E/BXnbdIyLOJqhxChSvyKdfDMjErKvptafltABkHeJQJzDw7IOET0x1VwBF3ZJXZ PD5mUs5yylD/E6fsCtRQPJrsfX4o= Received: from dhcp-10-61-97-137.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 3CF0D60A9; Wed, 22 Jan 2014 13:57:16 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_B3BADBED-8AD5-485E-A768-547DF363A025"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Reducing the battery impact of ND From: Ole Troan In-Reply-To: <52E03BB4.8040309@acm.org> Date: Wed, 22 Jan 2014 22:57:13 +0100 Message-Id: References: <52D96663.6060005@sonic.net> <52DA0ABA.8030903@acm.org> <52E03BB4.8040309@acm.org> To: Erik Nordmark X-Mailer: Apple Mail (2.1827) Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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:57:22 -0000 --Apple-Mail=_B3BADBED-8AD5-485E-A768-547DF363A025 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Erik, >> 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. >=20 > Lorenzo, >=20 > Whether you call it "efficiency" or "robustness" doesn't make much = difference from a technical or a process perspective. >=20 > The approach you advocate is insufficient to ensure better robustness = for at least two reasons: > - the lifetime(s) of the prefixes are independent of the lifetimes of = the default routers. Hence in this approach a host can have default = routers but no prefixes. > - the reachability state in the NCEs is independent of the default = router list - per RFC 4861 the router stays in the default router list = even if it is unreachable. Thus your last router might be unreachable = but with remaining lifetime - it was the next-to-last router in the list = that was reachable. >=20 > Solving those without risking hosts sending lots of RSs during failure = events or resulting in a steady state of RSs from hosts seems tricky. >=20 >> FWIW I don't have a problem with an opt-in update to 4861. I even >> think efficient-nd is the way to go because it reduces overall ND >> multicast traffic and not just your narrow focus on mobile phone >> battery life. >>=20 >>=20 >> The tradeoff is that efficient ND adds more state to the network = about >> host addresses and changes a pretty core part of the IPv6 specs. I = think >> that if we can reduce the battery impact of multicast traffic, we = will >> have fixed most of the problem without doing either of those, and to = my >> mind, that's a much better tradeoff. >=20 > Changing from periodic RAs to (effectively) periodic RSs as you = propose would change RFC 4861 is a very fundamental way. >=20 > It may or may not be the right thing to do for the future, but I think = that requires a bit more work then forcing some edits into a document = which has almost completed the WG process. I think resilient-rs has = significant benefits in its current form and scope. not trying to speak for Lorenzo, but I don't think he is proposing = replacing periodic RAs with periodic RSs. 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 cheers, Ole --Apple-Mail=_B3BADBED-8AD5-485E-A768-547DF363A025 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 iQEcBAEBCgAGBQJS4D65AAoJEFuJXizso86g09AH/jH3vrlm/nxYnEFZW+sqBLAl 5239FsB2Tl9FwikPsBYIijaIHEJll4sGrErl6rU5H6gbSk2kum+/ZWPBC+5UTviJ dP7k7uGfwPozDCmGaQSPD3TAldUMTq49nE0BXJFNuBdYWq+9pdsCA673CLmNj0Xk Qj/HulLl2aU0B10YyVEdT4rGsnRStLVdDV35T8eA8YGHtrIBmHiWt9to9szLdWrZ XZSlYiBsJuejlZB3cMlzWWmJkdieOLZQ/Oyc10riZW1F5MWvlhRQmbwr3D5RUwgw ANEwcQAZ4Mizq6an8+AxtMf/12dBYMeGacbWlk93YkmHMDPo77DmdN0s38kCfmo= =Vaux -----END PGP SIGNATURE----- --Apple-Mail=_B3BADBED-8AD5-485E-A768-547DF363A025-- From brian@innovationslab.net Wed Jan 22 13:59: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 615781A04B9; Wed, 22 Jan 2014 13:59:04 -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 XNVNa2jhWMPK; Wed, 22 Jan 2014 13:59:02 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 822AB1A0111; Wed, 22 Jan 2014 13:59:02 -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 30DBC8810A; Wed, 22 Jan 2014 13:59:02 -0800 (PST) Received: from clemson.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 5A2F9130003; Wed, 22 Jan 2014 13:59:01 -0800 (PST) Message-ID: <52E03F1D.3000307@innovationslab.net> Date: Wed, 22 Jan 2014 16:58:53 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Fernando Gont , Pete Resnick , Fernando Gont Subject: Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT) References: <20140122192018.8692.82071.idtracker@ietfa.amsl.com> <52E02C0C.7080901@si6networks.com> <52E0322C.1000301@qti.qualcomm.com> <52E03DCB.4060101@gont.com.ar> In-Reply-To: <52E03DCB.4060101@gont.com.ar> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8GmAHl8lhWt5g4gI98EL4XPBQEG54hs68" Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, The IESG , 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, 22 Jan 2014 21:59:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8GmAHl8lhWt5g4gI98EL4XPBQEG54hs68 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/22/14 4:53 PM, Fernando Gont wrote: > On 01/22/2014 06:03 PM, Pete Resnick wrote: >>>> This is an algorithm to generate stable, private, and mostly unique >>>> addresses. It does not affect interoperability at all if people choo= se a >>>> different method. >>>> =20 >>> The short answer to this is what Bob has already responding: >>> >>> We currently require nodes to embed their hardware address in the IID= >>> when they do SLAAC. And every other specification to generate IIDs is= >>> also Std track. So we are being consistent. >> >> As you might have guessed, consistently doing the incorrect thing isn'= t >> terribly convincing to me. >=20 > If how you select an IID is not std track, prepare for lazy > implementations to set the IID to "1" and hence for collisions to becom= e > common. At that point that becomes an interoperability problem. And that vendor will be smacked eventually. I see Pete's point and I agree that this document could be Informational. Especially since the WG *just* adopted a document that will be BCP giving guidance on which IID generation mechanisms are preferred. >=20 > And, a folk working on a v6 stack needs to implement *something*. When > he gets to the point of generating an IID, there's something he has to > follow. This document is one way to do it. With specific goals in mind.= > And specific requirements if you mean to meet does goals. >=20 > That looks std track to me. >=20 Except that the implementer could do any number of things and it would not impact interoperability. And I will note that you can use 2119 keywords in an Informational document so that someone following the spec gets the same behavior as someone else who follows the spec. >=20 >=20 >>> All the above said, there are many documents from different areas whe= re >>> we have std track RFCs which "do not affect interoperability". e.g. T= CP >>> congestion control, TCPs initial RTO, etc. which, from your pov, shou= ld >>> be informational? >> >> I'm happy to extend "interoperability" to mean "an individual host won= 't >> screw up the net for everybody else, even if it's not directly >> communicating with it."=20 >=20 > That's not interoperability, but a different goal. At that point, you'r= e > doing your own thing rather than the Section 6 of RFC2119 you're quotin= g. >=20 >=20 >> Perhaps 6410 has simply done away with the whole notion of what it is = to >> standardize things. Maybe I'm in the rough. But I think local >> configuration options and ways to do things that are not about >> interoperably communicating across the Internet have no place in the >> standards track. >=20 > If the "local policy" results in a high number of collisions, which > subsequently result in a high number of retries, you might find that th= e > local policy now has interoperability implications. >=20 > It's entirely local policy if it the whole thing relies on your node. > But when it comes to IIDs, they are required to be unique. And that's > not "local" anymore (or not "local to the host", at least). But DAD helps with uniqueness. Regards, Brian --8GmAHl8lhWt5g4gI98EL4XPBQEG54hs68 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 iQEcBAEBCgAGBQJS4D8kAAoJEBOZRqCi7goqSy8H/3G+mLjMdjvWu46+x3eONWA8 gm3CYf1tODcKhztz+peWZbNIdHAJ3O9ZMCIBF129vapWlAFCIPmRteerxSCjLyPY Zf1ijpp0h8HLLRVx9qZszI6G5K+K8IY2pS5PWAzfyGMbuG2XV+4/728OnkAP6u67 NYmwBrgo4v76i11eir/Q+z5p4jtmeZ+bcICQtvoTytPCZu4iDQHFx948Xua1zq8a uqcnXc6LINZ42XBo7W9DczA3ehh6TcbNP1/B4i8xNyGNr+IvEinhhEddlk5KN6R3 w3zbashOgWLwZ79I4Gg5L1Sue7ztvlxnb67c/NXc/eXEit1BHkOmWPNvroqOUDE= =Fpwe -----END PGP SIGNATURE----- --8GmAHl8lhWt5g4gI98EL4XPBQEG54hs68-- From otroan@employees.org Wed Jan 22 14:00: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 0697F1A03BF for ; Wed, 22 Jan 2014 14:00: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, 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 Gvba0EOAkQey for ; Wed, 22 Jan 2014 14:00:37 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 553511A0171 for ; Wed, 22 Jan 2014 14:00:37 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFANk+4FKQ/khL/2dsb2JhbABbgwy8bIETFnSCJQEBAQRuCxALGC5XBhOIBcQSF458B4MkgRQEkDuEAZV+gy47 X-IronPort-AV: E=Sophos;i="4.95,702,1384300800"; d="asc'?scan'208";a="3363978" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 22 Jan 2014 22:00:35 +0000 Received: from dhcp-10-61-97-137.cisco.com (dhcp-10-61-97-137.cisco.com [10.61.97.137]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0MM0Yhl031208 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Jan 2014 22:00:35 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_52E9E447-A187-4274-BFB9-6B0B12A2F28B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt From: Ole Troan In-Reply-To: <52E03E13.8080800@acm.org> Date: Wed, 22 Jan 2014 23:00:34 +0100 Message-Id: <25AE033D-3671-479E-A739-6C5F7DF221E1@employees.org> References: <20131021233827.32495.34424.idtracker@ietfa.amsl.com> <6299FD64-01A9-4F19-B271-9891AFCA3269@gmail.com> <52E03E13.8080800@acm.org> To: Erik Nordmark X-Mailer: Apple Mail (2.1827) 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:00:39 -0000 --Apple-Mail=_52E9E447-A187-4274-BFB9-6B0B12A2F28B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Erik, >>> [Resending with hopefully correct author mailing list] >>>=20 >>>=20 >>> On Wed, Jan 22, 2014 at 11:46 AM, Lorenzo Colitti = wrote: >>> On Mon, Oct 21, 2013 at 4:38 PM, wrote: >>> When an interface on a host is initialized, the host transmits = Router >>> Solicitations in order to minimize the amount of time it needs to >>> wait until the next unsolicited multicast Router Advertisement is >>> received. In certain scenarios, these router solicitations >>> transmitted by the host might be lost. This document specifies a >>> mechanism for hosts to cope with the loss of the initial Router >>> Solicitations. 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. >>>=20 >>> Authors, >>>=20 >>> One comment here. >>>=20 >>> If the intent is that we should be able to run networks that do not = send periodic RAs at all, then this document will need to require that = hosts send router solicitations when their RAs (or whatever is in the RA = contents, including lifetimes of PIOs, RIOs, RDNSS options, etc.) are = about to expire - otherwise the hosts will lose connectivity. >>=20 >> I think it's worse than that. >>=20 >> A host on a multicast-capable link on which "unsolicited multicast = Router Advertisements are never sent" will have to use the same = transmission behavior as a host on a non-multicast-capable link, so that = the host can learn of changes in the link prefixes in a timely fashion. >>=20 >> Furthermore, a host on a multicast-capable link won't know if = multicast RAs are being sent on the link, so all hosts will have to send = periodic RSs. >=20 > Even if you jump to a period RS from every host approach, there would = still be operational questions on what timer to use, and whether there = is a way for the operator to quickly introduce a new prefix (and retire = an old prefix). >=20 > With multicast RAs the operator can change the list of prefixes (to = handle some problem) quite quickly. To accomplish the same thing without = the multicast RA option would imply either > - frequent periodic RSs from all the hosts, or > - robustly tracking the set of hosts in the routers so that unicast = RAs can be used for such changes. 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 --Apple-Mail=_52E9E447-A187-4274-BFB9-6B0B12A2F28B 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 iQEcBAEBCgAGBQJS4D+CAAoJEFuJXizso86gEVAH/1zh5fV0PdOlaopAGbNxhyeS V+fZKh0L5ZEmrg+Hft41PvLby4y951Y0hmDpjkGA+awLZyCl3tP+z95D9mGoRlPm 4RqJVXqNe2kdJHPdTf/iZ0nTra4cTduc7wBY4SFPf9kRS3Cyn+gLZ13+GIYC+8Zo JXmDqiHIjT85uj+7TmFi3BKn0HV5VOxkjF8/og/EEh/lq7DFgQ5NDzIpsWwsC7L5 WexG5FIU24Zz1qdLlR4cTs8hK8j8O/X7sbsPDUv+R6wLRFM473vctv+a3TJxGXZt jmsCjjwfu6dfYfcji62gQr9Q+yDMc+1AXAyKtWOPTL7w7pDJrbnJosROJMPp2PA= =MbdJ -----END PGP SIGNATURE----- --Apple-Mail=_52E9E447-A187-4274-BFB9-6B0B12A2F28B-- From nordmark@acm.org Wed Jan 22 14:01: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 E40151A038D for ; Wed, 22 Jan 2014 14:01:18 -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 JX933oWqamja for ; Wed, 22 Jan 2014 14:01:17 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 341571A04BD for ; Wed, 22 Jan 2014 14:01:14 -0800 (PST) Received: from [10.0.1.44] (184-23-158-201.dsl.dynamic.sonic.net [184.23.158.201]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s0MM1Avo010445 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 22 Jan 2014 14:01:11 -0800 Message-ID: <52E03FA6.3020806@acm.org> Date: Wed, 22 Jan 2014 14:01:10 -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: IETF IPv6 Subject: Fwd: Re: Reducing the battery impact of ND References: <52E03C9D.7010605@sonic.net> In-Reply-To: <52E03C9D.7010605@sonic.net> X-Forwarded-Message-Id: <52E03C9D.7010605@sonic.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;ZlXls7CD4xGtyvMsIE/FGg== M;GiwUtLCD4xGtyvMsIE/FGg== 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:01:19 -0000 [I don't think this made it to the list.] -------- Original Message -------- Subject: Re: Reducing the battery impact of ND Date: Wed, 22 Jan 2014 13:48:13 -0800 From: Erik Nordmark To: Ole Troan , Lorenzo Colitti CC: Erik Nordmark , Andrew Yourtchenko , 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG 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@acm.org Wed Jan 22 14:03: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 87F301A04CF for ; Wed, 22 Jan 2014 14:03:10 -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 Qioh6BCy3ROC for ; Wed, 22 Jan 2014 14:03:09 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id CE1A61A04CD for ; Wed, 22 Jan 2014 14:03:09 -0800 (PST) Received: from [10.0.1.44] (184-23-158-201.dsl.dynamic.sonic.net [184.23.158.201]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s0MM05FH009334 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 22 Jan 2014 14:00:06 -0800 Message-ID: <52E03F65.5030700@acm.org> Date: Wed, 22 Jan 2014 14:00:05 -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 Subject: Re: Reducing the battery impact of ND References: <52D96663.6060005@sonic.net> <52DA0ABA.8030903@acm.org> <52E03C9D.7010605@sonic.net> <6D5AD847-30B2-467A-87B6-31C089C9380F@employees.org> In-Reply-To: <6D5AD847-30B2-467A-87B6-31C089C9380F@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;trkbjbCD4xGd1/MsIE/FGg== M;cLtQjbCD4xGd1/MsIE/FGg== Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Erik Nordmark , 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: Wed, 22 Jan 2014 22:03:10 -0000 On 1/22/14 1:52 PM, Ole Troan wrote: > Erik, > >>>> 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. > > the first reading implies that the host looses connectivity after router lifetime seconds. > "never sent" doesn't leave much room for interpretation. That would only be true if resilent-rs claims that no periodic unsolicited RAs are needed. I don't see any such text in the protocol specification in that draft (section 2-4). The introductory text talks about scenarios, and perhaps that scenario text doesn't match what the proposed protocol actually does? Thus the document needs to be more clear. Regards, Erik From nordmark@acm.org Wed Jan 22 14:12: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 1BFEE1A012E for ; Wed, 22 Jan 2014 14:12:19 -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 OqJYYgRmm0k2 for ; Wed, 22 Jan 2014 14:12:18 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 09FD71A010C for ; Wed, 22 Jan 2014 14:12:18 -0800 (PST) Received: from [10.0.1.44] (184-23-158-201.dsl.dynamic.sonic.net [184.23.158.201]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s0MMCAPI019783 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 22 Jan 2014 14:12:10 -0800 Message-ID: <52E0423A.5070906@acm.org> Date: Wed, 22 Jan 2014 14:12:10 -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: Reducing the battery impact of ND References: <52D96663.6060005@sonic.net> <52DA0ABA.8030903@acm.org> <52E03BB4.8040309@acm.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;Vsb+PLKD4xGtluozIE/FGg== M;sAEyPbKD4xGtluozIE/FGg== Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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 22:12:19 -0000 On 1/22/14 1:57 PM, Ole Troan wrote: >> It may or may not be the right thing to do for the future, but I think that requires a bit more work then forcing some edits into a document which has almost completed the WG process. I think resilient-rs has significant benefits in its current form and scope. > > not trying to speak for Lorenzo, but I don't think he is proposing replacing periodic RAs with periodic RSs. Ole, I think that is the effective result of what you two are cooking up. > 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). You are speculating about some particular failure or misfeature in the network that makes it (persistently? sometimes?) drop multicast RAs. It would be good to flesh out that particular failure mode to see - whether it is realistic, and - what impact it has elsewhere. For instance, the failure could be that all ICMP packets to the host are dropped (due to some misconfigured security policy - we've seen those in IPv4). That would drop unicast RAs as well, and affect the old path MTU discovery protocol. Or it could be that link-local multicast is misconfigured or broken, resulting in DNSSD and other protocols breaking. Having every host on the planet send a RS every 30 seconds "just in case" doesn't sound helpful. Erik > 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 > > cheers, > Ole > From fernando@gont.com.ar Wed Jan 22 14:15: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 DB3961A0242; Wed, 22 Jan 2014 14:15:31 -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 wcQjTbb74nrd; Wed, 22 Jan 2014 14:15:30 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 99AB71A04D9; Wed, 22 Jan 2014 14:14:53 -0800 (PST) Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W664N-00032I-08; Wed, 22 Jan 2014 23:14:47 +0100 Message-ID: <52E04278.1000401@gont.com.ar> Date: Wed, 22 Jan 2014 19:13:12 -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 Haberman , Fernando Gont , The IESG Subject: Re: Brian Haberman's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS) References: <20140122202434.30069.4084.idtracker@ietfa.amsl.com> <52E02EAD.1050009@si6networks.com> <52E03BAD.5050306@innovationslab.net> In-Reply-To: <52E03BAD.5050306@innovationslab.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Wed, 22 Jan 2014 22:15:32 -0000 Hi, Brian, Comments in-line... (important bit at the bottom :-) ).. On 01/22/2014 06:44 PM, Brian Haberman wrote: >> >> 1) Recording the addresses a node has visited during its lifetime >> would somehow be ironic for a document aiming at privacy. Just >> get the document compromised, and you get a list of where the >> node has been since it was first installed. > > I think I can get a list of where a device has been from any number > of places. I guess you might. However, I don't think that means one should add yet another one. >> 2) Recording the addresses seems like a waste of resources. How >> many networks you connect to only once in your lifetime? > > Uh, storing 16 (or so) bytes per location is rather low-cost. Firstly, you might not have such stable storage. Secondly, where do you stop? 10 addresses? 100 addresses? 1000 addresses? Why should we rely on such stable storage when we need not? Thirdly, recording the addresses seems to be a different scheme than this one, which aims at producing stable addresses stateless-ly. >>> DNA does this. Seems like that option should be allowed. (the >>> current document suggests saving the number of DAD iterations >>> in stable storage... why do that if you can just save the >>> address itself?) >> >> The current document allows that to happen for cases where you >> find a colission -- which would be close to nil, given that >> subnets are /64 and the IIDs are essentially random. >> >> That said, as an author, I don't expect implementations to record >> the dad counter ever, even in the presence of collisions. I'd >> argue that that paragraph is there with this rationale "if you're >> picky and you're going to argue that this spec doesn't guarantee >> a stable IID, you can do this if you want". > > Now you are getting into specifying implementation details and that > is not good. I was just clarifying that while the document says you MAY do something that requires stable storage, the mechanism does not really depend on it. > All this point is making is that there are a variety of ways of > getting this behavior and DNA provided guidance on one way to do > that. The simple solution is to refer to those RFCs > (informatively) and point out that they describe one way to track > which addresses are associated with particular networks. This has > the benefit of not forcing re-calculation of the hash on every > (re-)connect. I have no issues with that (I misinterpreted where you were going, it seems). So I guess one could add something along the lines of: "A node may use Simple DNA [RFC6059] to reuse a previously-configured address for this network without the need to recompute the Interface-ID with the scheme specified in this document." ? 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 otroan@employees.org Wed Jan 22 14:18: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 39EEE1A04BF for ; Wed, 22 Jan 2014 14:18:41 -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, 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 jQGBMm2bL9hU for ; Wed, 22 Jan 2014 14:18:37 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9442E1A0392 for ; Wed, 22 Jan 2014 14:18:37 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFANtC4FKQ/khN/2dsb2JhbABbgwy8bIETFnSCJQEBAQMBeQULC0ZXBogQCKZdnTkXjnwHgySBFAEDkDuZf4MuOw X-IronPort-AV: E=Sophos;i="4.95,702,1384300800"; d="asc'?scan'208";a="4034075" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 22 Jan 2014 22:18:36 +0000 Received: from dhcp-10-61-97-137.cisco.com (dhcp-10-61-97-137.cisco.com [10.61.97.137]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0MMIYsx019296 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Jan 2014 22:18:35 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_1DAFC1B1-1E21-4535-B322-F0A357C168D7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt From: Ole Troan In-Reply-To: <52E042C7.2090906@sonic.net> Date: Wed, 22 Jan 2014 23:18:34 +0100 Message-Id: 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> <52E042C7.2090906@sonic.net> To: Erik Nordmark X-Mailer: Apple Mail (2.1827) Cc: Erik Nordmark , 6man WG , Ralph Droms , draft-ietf-6man-resilient-rs@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, 22 Jan 2014 22:18:41 -0000 --Apple-Mail=_1DAFC1B1-1E21-4535-B322-F0A357C168D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Erik, > 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. as a working group contributor. there clearly isn't any consensus to gauge, given that the issue = identified as brand new. >> 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 --Apple-Mail=_1DAFC1B1-1E21-4535-B322-F0A357C168D7 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 iQEcBAEBCgAGBQJS4EO6AAoJEFuJXizso86gayoIALLpkSQol/GCaLQRpzczysnL grbjuXqlrgIPcpNf5A4HoIIqgKpNPfbsKcVqMqn0fDg5jyoRXlab2K0+jn88SxT9 q+SIyANLHUdBZToTK4wZ+QbNR9tnf03EhHoIV4A+R2obPWW+kMwVBNV3cbiLAPdz 6Azx60gcsZh7py9h/3axHWPSe6T2SUjhZFdQ+nhQX+AAqXnqsDcyrP0mDZxCnKIx BelF5ZPqf1drinMDS+OVDJfVdjVK2WJdoppO49do3JeTp38fSiC7dqGeLVYO9sen ppvv9+6O7sfWrWNuvMu9Zy06M3n2N68GA6pjJMaKg5D3laB8/LjubdfNcYm1pck= =FOL9 -----END PGP SIGNATURE----- --Apple-Mail=_1DAFC1B1-1E21-4535-B322-F0A357C168D7-- From stephen.farrell@cs.tcd.ie Wed Jan 22 14: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 319B31A0460; Wed, 22 Jan 2014 14:31:19 -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, 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 uxTNNNtGmkXe; Wed, 22 Jan 2014 14:31:15 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0CE1A0242; Wed, 22 Jan 2014 14:31:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 46059BE47; Wed, 22 Jan 2014 22:31:14 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4owoRYNu4XN; Wed, 22 Jan 2014 22:31:12 +0000 (GMT) Received: from [10.87.48.3] (unknown [86.44.74.137]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6B569BE39; Wed, 22 Jan 2014 22:31:12 +0000 (GMT) Message-ID: <52E046B0.1000701@cs.tcd.ie> Date: Wed, 22 Jan 2014 22:31:12 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Brian Haberman , Fernando Gont , The IESG Subject: Re: Brian Haberman's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS) References: <20140122202434.30069.4084.idtracker@ietfa.amsl.com> <52E02EAD.1050009@si6networks.com> <52E03BAD.5050306@innovationslab.net> In-Reply-To: <52E03BAD.5050306@innovationslab.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Wed, 22 Jan 2014 22:31:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/22/2014 09:44 PM, Brian Haberman wrote: >>> 1) Recording the addresses a node has visited during its >>> lifetime would somehow be ironic for a document aiming at >>> privacy. Just get the document compromised, and you get a list >>> of where the node has been since it was first installed. > I think I can get a list of where a device has been from any number > of places. So, I don't buy that argument at all. > I buy the argument. Some vendors have been beaten up for it now and then. Making that worse while trying to make privacy better would be a shame, no? S. [1] http://www.theguardian.com/technology/2011/apr/20/iphone-tracking-prompts-privacy-fears -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJS4EatAAoJEC88hzaAX42ioFEH/juQiyETbJga5sKS6IyjAqtF 1m7qzYKEYQyI380xCO1Hy1CCW3nx7D5de7hlbpGAjnyIW8VzUjgAhopWqNhSg6x3 QlPm/9W39oqEuaJvsqWv8O/hwbSMPwUHCsR+7uhET/PrMXAIB4pyJp/g3qn3RijY JkBGMBAnJ6R9lGisGaXr4h7xrJZSI0a98q4dVEj07R6GHFuPlV+JSFt0bnXKZgOi XepYr9lVZ4MDTGqOg9Qdrj8SC1qk7XuRS1DeaXjnN2Go5wQMybsA3UPta6AdSXRM sleK5eziKYuuvPwRFRAHWfJEaMuLUdhNnlFd7L7e8OtOnMFu00MO2qqtf5JdAeU= =w4PC -----END PGP SIGNATURE----- From lorenzo@google.com Wed Jan 22 14:48: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 C2FBA1A04F9 for ; Wed, 22 Jan 2014 14:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 h_ESTAQmljzH for ; Wed, 22 Jan 2014 14:48:55 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C04EB1A04D3 for ; Wed, 22 Jan 2014 14:48:55 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id as1so266634iec.2 for ; Wed, 22 Jan 2014 14:48:55 -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=IdzyrsDkQUZT0Wto9sx7I9lF7o5yF5EATuaVsAhGUOU=; b=nBlFxwuoLY1EDrw2ewqSTdRDRXSIT9pyV4H4Mx6Evy3aTOs8/dXOMhBJ90xcQB2OYz QeTXthsLsNDtU3AsrI3T4ZDApBAi4GvHu3z8pQAAv2fuTBHozWzejjyDx6wDTVSAHah/ CUHXTcp6kqS3UsXO7QLpkKUj1cPOaE2ppZ4Dit5FBZ4j6LrmpI2dWXE0yh4gvhDW1lbH gVbVjyk5467A69gxPIn+i+DcaMXfdRZd/SZ1D0BUspUCyKwE/NRDuDqAYRFbpLO0DQN9 meAm2FYJMS0VzyRRLAVEyNlA7hStjzi9rvdTdQGJCncankvvTv3lFjM/1ivJDlEQmZ9p nPTA== 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=IdzyrsDkQUZT0Wto9sx7I9lF7o5yF5EATuaVsAhGUOU=; b=gvw1SEsE91I2AiavhyRGl8pgxuQwrxcftVyBrrWu5av2DP5S08shbypHQ+mOarvp37 fWqyE9A3GIVeiO0A7v1DIxNj7DZevuTlkX0HtUzmyBw4elBbGOzFT43fm38PMlGpjYbg ueuyK4kyHVb/jg7CJgRVh3Vxgjq9uWTG8WqPG85Zy65qACO+EG7ulA6ZiVeVgNv54Dip I0R8y97Hj7I/Larxszz+xVCM4UQI4FeIygYg8GqOEqqrHWJ7wGyK9YE/Xn7ysGKiOXgD U7ZXo9nVrwD+0GqGmI6TjSlRrlM3+guihLwjJgxNOuBH0hB1F7pwcI2V9/UCL5inWWyQ Xg2Q== X-Gm-Message-State: ALoCoQmCYZTkheoyGUr/ppdUxf7BRoHxFVVjMaGQG9hmWMQISQ7wAzTF8IQr2lC7+e8g18dRpiyAp+vfU0AFnNbQ6CwpiPi7/ObiCj9wKwhIZ7kONweTIqF32l7ZtvI7Om7BeBWMgfZxgrlaJ+UHFlcFA0/F8If1XmVnUAXlsoqvY/BwB6sgGnyWZuCOK/BTYCQDX6rXFcUY X-Received: by 10.50.176.137 with SMTP id ci9mr26406940igc.31.1390430934971; Wed, 22 Jan 2014 14:48:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 22 Jan 2014 14:48:34 -0800 (PST) In-Reply-To: <52E03BB4.8040309@acm.org> References: <52D96663.6060005@sonic.net> <52DA0ABA.8030903@acm.org> <52E03BB4.8040309@acm.org> From: Lorenzo Colitti Date: Wed, 22 Jan 2014 14:48:34 -0800 Message-ID: Subject: Re: Reducing the battery impact of ND To: Erik Nordmark Content-Type: multipart/alternative; boundary=089e0111e0daf6d82104f096ed2b Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG , =?UTF-8?Q?Andrew_=F0=9F=91=BD_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: Wed, 22 Jan 2014 22:48:58 -0000 --089e0111e0daf6d82104f096ed2b Content-Type: text/plain; charset=UTF-8 On Wed, Jan 22, 2014 at 1:44 PM, Erik Nordmark wrote: > The approach you advocate is insufficient to ensure better robustness for > at least two reasons: > - the lifetime(s) of the prefixes are independent of the lifetimes of > the default routers. Hence in this approach a host can have default routers > but no prefixes. > This can be tricky to implement, but in principle, the host has this information already. > - the reachability state in the NCEs is independent of the default router > list - per RFC 4861 the router stays in the default router list even if it > is unreachable. Thus your last router might be unreachable but with > remaining lifetime - it was the next-to-last router in the list that was > reachable. > > Solving those without risking hosts sending lots of RSs during failure > events or resulting in a steady state of RSs from hosts seems tricky. I agree that there are a lot of corner cases here. > Changing from periodic RAs to (effectively) periodic RSs as you propose > would change RFC 4861 is a very fundamental way. > > It may or may not be the right thing to do for the future, but I think > that requires a bit more work then forcing some edits into a document which > has almost completed the WG process. I think resilient-rs has significant > benefits in its current form and scope. > Fair enough. That said - if that's what we want to do, then resilient-rs should make it clear that it is only for initial solicitations and thus does not specify or allow behaviour on multicast-capable links where there are no periodic multicast RAs, because the IPv6 standards as written do not work on such links. --089e0111e0daf6d82104f096ed2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 22, 2014 at 1:44 PM, Erik Nordmark <nordmark@acm.org>= wrote:
The approach you advocate is insufficient to ensure better robust= ness for at least two reasons:
=C2=A0- the lifetime(s) of the prefixes are independent of the lifetimes of= the default routers. Hence in this approach a host can have default router= s but no prefixes.

This can be tricky t= o implement, but in principle, the host has this information already.
=C2=A0
=C2=A0- the reachability state in the NCEs is independent of the default ro= uter list - per RFC 4861 the router stays in the default router list even i= f it is unreachable. Thus your last router might be unreachable but with re= maining lifetime - it was the next-to-last router in the list that was reac= hable.

Solving those without risking hosts sending lots of RSs during failure even= ts or resulting in a steady state of RSs from hosts seems tricky.

I agree that there are a lot of corner cases here.
=C2=A0
Changing from periodic RAs to (effectively) peri= odic RSs as you propose would change RFC 4861 is a very fundamental way.

It may or may not be the right thing to do for the future, but I think that= requires a bit more work then forcing some edits into a document which has= almost completed the WG process. I think resilient-rs has significant bene= fits in its current form and scope.

Fair enough. That said - if that's wha= t we want to do, then resilient-rs should make it clear that it is only for= initial solicitations and thus does not specify or allow behaviour on mult= icast-capable links where there are no periodic multicast RAs, because the = IPv6 standards as written do not work on such links.
--089e0111e0daf6d82104f096ed2b-- From lorenzo@google.com Wed Jan 22 14:54: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 A2C131A04DC for ; Wed, 22 Jan 2014 14:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 9qgQbqgNC4qa for ; Wed, 22 Jan 2014 14:54:20 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAD81A04E5 for ; Wed, 22 Jan 2014 14:54:20 -0800 (PST) Received: by mail-ig0-f177.google.com with SMTP id k19so3053717igc.4 for ; Wed, 22 Jan 2014 14:54:19 -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=nOTeCZRIjsOHDXriMIp4i4QdjizKPF4S2CGjX+Z5Xv8=; b=AWLrgRAqMV62SZcHZOHnGn2qJpBmks8Ra2pVSH8lPh7fGM31oiaiQukbyM/vVC/pwN row3o+JGpQOE1r+vhcitVYMKLhUFB8OtsAp1shOb8mjGwU/Pu0Zq7ChkhYb9+t4rv5Np qeP1tFPE1qEPKHxkv4CUPNvgXmDxCpDfxkWNPTwLpse90+WR4i+LK0KtxJpgGIt4eojy N+Hm6haE3ggY0cGvUdI+VGGIgVjwi4KhTJ2OwvmcXrQFi/lgx5RwrgEFyw/+5lS/YH3c ivIletzMp/c/QJVQvNH9pWVQEbKzs7u4g3HT6qxrkg/PULQyoqYb34RbbhxtkC2TAtga aBZA== 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=nOTeCZRIjsOHDXriMIp4i4QdjizKPF4S2CGjX+Z5Xv8=; b=N1ceY8NRuk9ZHZrpSjwu8n57uvVXzzPSfvOxUpY26GACTZVD7tIQff6CigWfgdkzCG 7VBduSIK9eeRhyj22kr1No2ya3yiZZzF9A5DRHnmJmaFo/fVuY2fEJTZE5yrbm3Bv/MS r+A+o0Wfk4/FHcKdMZY0z+5777o+QnB5MU8NzNeKgGC9IK097nAhLeABsc/xjko/xqHz tJMQn6vBz+rq9d33ffhV9xG+67fxpGjGelH4nA1UylXps+1iB5mr4aG6fy2dDNgxf8IZ ymYMnEcC+NVse1nfan0ZbgN6g02RdGuf+fiNBSuNfSgu2PsW30lcIXhtftlmO+5v/5i1 yrlA== X-Gm-Message-State: ALoCoQlnkIOrYcU9TV2z4wdb6eX6v1mcd6qZX+w9unwix9SDxTfAzq04pHkZMiKo7kxXN6WFJbKm++7ENi/nb2fSysIjLGqhTcb01PuUAypBIvJppt//X8BZA+9Mr/qEXhsOZY9zEtVtoMqwCZrSFsQexGNSuiTeZZMAr5sHTfKjgCfA3uDLwYl9qTDAVRSJyGxfwnihQw+V X-Received: by 10.50.61.137 with SMTP id p9mr26348759igr.45.1390431259412; Wed, 22 Jan 2014 14:54:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 22 Jan 2014 14:53:57 -0800 (PST) In-Reply-To: <25AE033D-3671-479E-A739-6C5F7DF221E1@employees.org> 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> From: Lorenzo Colitti Date: Wed, 22 Jan 2014 14:53:57 -0800 Message-ID: Subject: Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt To: Ole Troan Content-Type: multipart/alternative; boundary=047d7bdca5dc4d840004f0970164 Cc: Erik Nordmark , 6man WG , Ralph Droms , draft-ietf-6man-resilient-rs 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:54:21 -0000 --047d7bdca5dc4d840004f0970164 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 22, 2014 at 2:00 PM, Ole Troan wrote: > 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. > Is it reasonable to say that a host that knows that RA-learned connectivity parameters (e.g., prefixes, default router, DNS servers) will expire shortly MAY send an RS in an effort to refresh those connectivity parameters before they expire and cause disruption? --047d7bdca5dc4d840004f0970164 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 22, 2014 at 2:00 PM, Ole Troan <otroan@employees.org> wrote:
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 robu= stly.

Is it reasonable to say that a ho= st that knows that RA-learned connectivity parameters (e.g., prefixes, defa= ult router, DNS servers) will expire shortly MAY send an RS in an effort to= refresh those connectivity parameters before they expire and cause disrupt= ion?
--047d7bdca5dc4d840004f0970164-- From bob.hinden@gmail.com Wed Jan 22 15:16: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 A259F1A0192; Wed, 22 Jan 2014 15:16:58 -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 5UH5eYi4cEpq; Wed, 22 Jan 2014 15:16:56 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 070551A012C; Wed, 22 Jan 2014 15:16:55 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id ex4so85867wid.3 for ; Wed, 22 Jan 2014 15:16:55 -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 :message-id:references:to; bh=+vHOjyFPc5XLzPJYBno+MJhyDV5Rap8ncGKGGCGpy24=; b=vqLbrOAC9uWUwFc9nhZ429VO9dwgucLQb70g6G+laL3TfezaqPsG80B5DTosw9sLKq kAzgE+OBxkt+Bq6f04wLjHfMMR7go5kjobHlhffsoi0NCqPkyf0CdjF7Mr8gALpfF9K7 iseWdqszg0fmkHKyHa2Qa8C8ZSN0DmJfRi4ktRzw/9JkZo+Py1LrdADMXg3fKviOau7d eUHMg9iT5NDWrIdKdcTtTfu4SE9UMEXby4c+BXulfemS+TEikOPkXlq28UmiIc1GZH4v v500jr1jmKKxF8yAXC7BoVAsleVykWsczW2Ed4AMcCiLfh885Iby9RHDNVZRLgqDPU9x M8vg== X-Received: by 10.194.83.9 with SMTP id m9mr994919wjy.39.1390432614953; Wed, 22 Jan 2014 15:16:54 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by mx.google.com with ESMTPSA id eg1sm19999072wib.0.2014.01.22.15.16.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jan 2014 15:16:53 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_7E5366CD-B50D-4F27-AE2B-51B75E5D03D6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT) From: Bob Hinden In-Reply-To: <52E03F1D.3000307@innovationslab.net> Date: Wed, 22 Jan 2014 15:16:49 -0800 Message-Id: <47E8B622-5F85-414A-B266-87B0C998E4CD@gmail.com> References: <20140122192018.8692.82071.idtracker@ietfa.amsl.com> <52E02C0C.7080901@si6networks.com> <52E0322C.1000301@qti.qualcomm.com> <52E03DCB.4060101@gont.com.ar> <52E03F1D.3000307@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1510) Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, Pete Resnick , Bob Hinden , Fernando Gont , draft-ietf-6man-stable-privacy-addresses@tools.ietf.org, Fernando Gont , The IESG 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 23:16:58 -0000 --Apple-Mail=_7E5366CD-B50D-4F27-AE2B-51B75E5D03D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Brian, >=20 > And that vendor will be smacked eventually. I see Pete's point and I > agree that this document could be Informational. Especially since the > WG *just* adopted a document that will be BCP giving guidance on which > IID generation mechanisms are preferred. >=20 While I don't think debating which IETF label to put on this document is = a very big issue as compared to the problem this draft solves, I have a = question about what will happen if we agree to change it to = Informational. Will this require a new IETF last call, or sending it = back to the working group and starting the process over? If it is more than resubmitting a new draft, then I think this falls = into the category of the "Perfect is the enemy of good". =20 Bob --Apple-Mail=_7E5366CD-B50D-4F27-AE2B-51B75E5D03D6 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 iQEcBAEBCgAGBQJS4FFhAAoJEK7rdBF357uoxAoH/2AmZNJ/7Lpa/Y1lrplqvWaB FoAKYTjEqPhHDXKc6L7f2g7pHLVm0wIN7LHUcJRfbBQ9hzD4ewEcDQLZ+rgxCCGV ZR4tenxm5+hj250H3DSFIZ8H0oLRlcNytyVBrN4S4Kafrsk8reyaUcoXr0TFTZSE bJrZk18yDi/D2yExaVnqYADnud+1gVDAmwxCKZUMktaEs4kbsc2u2QQtXa1y1qIu x0ciUtcuZjONzgAAj+rt57QfZSep9P+9xLkCAxe0ErMvaTgEULDXv9/TSIBQlTBv sT6l93SQ0ObVNj7jRMqoqZ5Pxq/7Bsfxls9qHgdfL9IHTi/JRRLrtonUqUf1X4c= =4FVa -----END PGP SIGNATURE----- --Apple-Mail=_7E5366CD-B50D-4F27-AE2B-51B75E5D03D6-- From presnick@qti.qualcomm.com Wed Jan 22 15:21: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 479C51A039D; Wed, 22 Jan 2014 15:21:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 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] 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 jeSN7hZ7owFB; Wed, 22 Jan 2014 15:21:58 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id DD7741A04EC; Wed, 22 Jan 2014 15:21:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1390432917; x=1421968917; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=iYqvvLdIH/A0cOzEYDezP3QEZZFEPI1M7FCI0RSY7Xo=; b=VndToyfbcK00BJefa1ocb9Wl5ej374gqqfZ/vy+Skg5cOMnpMmW7HInZ qqyoF/r5wSFJgCT95k/1bvg+iTFrfOTm1MwlzKHlXVMobuY4o4oXYpP1e HcWub9hCqgU6q9ajqlYwZ33e23EJ/Nm8XH/ra6XsI2rlJa/g22YbUHgnO Y=; X-IronPort-AV: E=McAfee;i="5400,1158,7326"; a="58422451" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP; 22 Jan 2014 15:21:57 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,7326"; a="617826758" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 22 Jan 2014 15:21:57 -0800 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Jan 2014 15:21:56 -0800 Message-ID: <52E05292.4000301@qti.qualcomm.com> Date: Wed, 22 Jan 2014 17:21:54 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Bob Hinden Subject: Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT) References: <20140122192018.8692.82071.idtracker@ietfa.amsl.com> <52E02C0C.7080901@si6networks.com> <52E0322C.1000301@qti.qualcomm.com> <52E03DCB.4060101@gont.com.ar> <52E03F1D.3000307@innovationslab.net> <47E8B622-5F85-414A-B266-87B0C998E4CD@gmail.com> In-Reply-To: <47E8B622-5F85-414A-B266-87B0C998E4CD@gmail.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: 6man-chairs@tools.ietf.org, Brian Haberman , ipv6@ietf.org, Fernando Gont , draft-ietf-6man-stable-privacy-addresses@tools.ietf.org, Fernando Gont , The IESG 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 23:21:59 -0000 On 1/22/14 5:16 PM, Bob Hinden wrote: > I have a question about what will happen if we agree to change it to Informational. Will this require a new IETF last call, or sending it back to the working group and starting the process over? > Nope. Going "down" in status just takes the wave of the IESG's magic wand. 2026, 6.1.2, paragraph 5. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From bob.hinden@gmail.com Wed Jan 22 15:31: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 04A581A0187; Wed, 22 Jan 2014 15:31:27 -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 U7mdEXOaSX34; Wed, 22 Jan 2014 15:31:25 -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 C6A6D1A00C8; Wed, 22 Jan 2014 15:31:24 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id q58so604017wes.3 for ; Wed, 22 Jan 2014 15:31:23 -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 :message-id:references:to; bh=l6fz33CG0CnlbUR2UXTL108yZT9PYcRytrxgcDFK4sA=; b=bgqA/uHbn+jD4idAnaFq8j1UGaOIWhAz7jJztNWbyI8aTqyAciCTPPDrH+muOWlN83 v9+rPrsIG4RhP/UrVTgqxhQdllV6QRsXoetZEvNdNB9XtEuwsFtlbYBXLlK2XdoQPkF2 7VrTRlDwjBBccwhrMMTusQB0qOUJCQg1GB463GLP/EW/3Sgawu+dgprejRd9S9/sZTyi vodoVjoSUK398vtrX62ObBytO2HLoiGBIQzy2PmzvHIliW5Tlr+VW+pF6D8yVnA+5D48 W5gY2i8B5bA/AJgiJ3ZwSnu/LR11NNqsiJjvmmmKsjHlnd6Jiatgr9fCU1KbxHDCgiUX y22Q== X-Received: by 10.180.37.193 with SMTP id a1mr5408179wik.52.1390433483609; Wed, 22 Jan 2014 15:31:23 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by mx.google.com with ESMTPSA id j9sm18046730wjz.13.2014.01.22.15.31.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jan 2014 15:31:19 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_7B0B18FF-F6F9-42E2-B267-612B9A49112A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT) From: Bob Hinden In-Reply-To: <52E05292.4000301@qti.qualcomm.com> Date: Wed, 22 Jan 2014 15:31:14 -0800 Message-Id: References: <20140122192018.8692.82071.idtracker@ietfa.amsl.com> <52E02C0C.7080901@si6networks.com> <52E0322C.1000301@qti.qualcomm.com> <52E03DCB.4060101@gont.com.ar> <52E03F1D.3000307@innovationslab.net> <47E8B622-5F85-414A-B266-87B0C998E4CD@gmail.com> <52E05292.4000301@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1510) Cc: 6man-chairs@tools.ietf.org, Brian Haberman , ipv6@ietf.org, Bob Hinden , Fernando Gont , draft-ietf-6man-stable-privacy-addresses@tools.ietf.org, Fernando Gont , The IESG 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 23:31:27 -0000 --Apple-Mail=_7B0B18FF-F6F9-42E2-B267-612B9A49112A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Pete, On Jan 22, 2014, at 3:21 PM, Pete Resnick = wrote: > On 1/22/14 5:16 PM, Bob Hinden wrote: >> I have a question about what will happen if we agree to change it to = Informational. Will this require a new IETF last call, or sending it = back to the working group and starting the process over? >> =20 >=20 > Nope. Going "down" in status just takes the wave of the IESG's magic = wand. 2026, 6.1.2, paragraph 5. Good, then I don't object. Better to get it through the process than = argue over the IETF label. =20 If there aren't objections from the w.g. then we can do that. Bob --Apple-Mail=_7B0B18FF-F6F9-42E2-B267-612B9A49112A 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 iQEcBAEBCgAGBQJS4FTCAAoJEK7rdBF357uoto8H+gKMbv3CH39zEdlNO2jLdqkb y9rPhoN/+PYsf/7xV/pPhIruBxbR/r3srVwp4wY/Iz2UGID2riWyurOkQUre3i2M FsNbDzaRDqoG04uCBKCxGykzBR39CeisdrgCeyf/KqgeYHm7RvvS+dqiOYlWoEO3 5v//VApcFFP40h5IAzTwNT7fV2xiQIziCM+cTA4wUvB4N8EDxPSXNPlDByuM2lea uiBp+o97xcetGtBwjDlwTC4wsVyznTI29IMKocNp0rx/8bELSgYm/mAnGRjI/grB 1F0jMEqk5sLbCMEKrcKiWn9ND1Nusxu9RRNVPUes9n1b4ZgumhbUQbMGhhglLbY= =I6Ah -----END PGP SIGNATURE----- --Apple-Mail=_7B0B18FF-F6F9-42E2-B267-612B9A49112A-- From presnick@qti.qualcomm.com Wed Jan 22 15:34: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 303A31A0514; Wed, 22 Jan 2014 15:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.836 X-Spam-Level: X-Spam-Status: No, score=-4.836 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_MED=-2.3, 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 lQTJ6H5OYaC2; Wed, 22 Jan 2014 15:34:18 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 125AD1A0511; Wed, 22 Jan 2014 15:34:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1390433659; x=1421969659; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=pvbEskZec1mWWpb547iH0FFxCi+KuQbHsXFOMfZ9r9k=; b=gsNvT3kK0/v+gBJvmeunrNXh86sC9yH4Fkt3m55sfC10PSihm9RtT5RQ VcU4W2mwwYIG9e2nXJXIjzXMU8pZEuuYQ5MLAGvhPd82HfHDwHwr+6aCY h4Fmp7cYfsJXzoQfdGYdt2CCLVXExAJ21S3yDy4CA1W31YUBpCkHRnSYL k=; X-IronPort-AV: E=McAfee;i="5400,1158,7326"; a="9831986" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 22 Jan 2014 15:34:19 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,7326"; a="617832276" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 22 Jan 2014 15:34:17 -0800 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Jan 2014 15:34:17 -0800 Message-ID: <52E05577.4070204@qti.qualcomm.com> Date: Wed, 22 Jan 2014 17:34:15 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Bob Hinden Subject: Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT) References: <20140122192018.8692.82071.idtracker@ietfa.amsl.com> <52E02C0C.7080901@si6networks.com> <52E0322C.1000301@qti.qualcomm.com> <52E03DCB.4060101@gont.com.ar> <52E03F1D.3000307@innovationslab.net> <47E8B622-5F85-414A-B266-87B0C998E4CD@gmail.com> <52E05292.4000301@qti.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: 6man-chairs@tools.ietf.org, Brian Haberman , ipv6@ietf.org, Fernando Gont , draft-ietf-6man-stable-privacy-addresses@tools.ietf.org, Fernando Gont , The IESG 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 23:34:20 -0000 On 1/22/14 5:31 PM, Bob Hinden wrote: > Pete, > > On Jan 22, 2014, at 3:21 PM, Pete Resnick wrote: > > >> On 1/22/14 5:16 PM, Bob Hinden wrote: >> >>> I have a question about what will happen if we agree to change it to Informational. Will this require a new IETF last call, or sending it back to the working group and starting the process over? >>> >>> >> Nope. Going "down" in status just takes the wave of the IESG's magic wand. 2026, 6.1.2, paragraph 5. >> > Good, then I don't object. Better to get it through the process than argue over the IETF label. > > If there aren't objections from the w.g. then we can do that. > But there might be objections from others on the IESG. That's why I ABSTAINed instead of DISCUSSed. I'm not willing to stand in the way either, even though I think the standards track outcome is not the right one. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From bob.hinden@gmail.com Wed Jan 22 15:38: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 11A281A0526; Wed, 22 Jan 2014 15:38: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 MfFNjiWS7JQE; Wed, 22 Jan 2014 15:38:24 -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 B06011A0511; Wed, 22 Jan 2014 15:38:23 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id q58so607349wes.3 for ; Wed, 22 Jan 2014 15:38:22 -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 :message-id:references:to; bh=S4Nd8xGom1o6Hu1uNpgNPXAxlTDLDj4/BXEzn+9N+xs=; b=YZ1S/RHpSzlBnJ+dVGphcA0DlIquYphZ2P657OUQE9wws37KryOcQHY9gTeml8bP1X 1o84E62T+ZbiYI9ImVFOvbdqrMILgmljSIua6PjOpgvctXd1mqNjhOx1JCS/KzpvE4Jx q27vmBOT4awo2YCyzKkw9dFfs1CDqiF41AuF4OPM91Uf+X3RDqBibjw9AwR0o3EmjoaZ nzctYcvI9s4eiqr6VAdBdWK/g85sMIo2zJMp6Wk8/QpxPyzIR2HUovB++OneHxhulJCS bW8tAq44V4cDLgpRHuzSc/KgIppWBw7/MkJmUQSWFdmG3tHvfbYsQ01mDTKDRrMQIvz2 Sr+Q== X-Received: by 10.180.19.130 with SMTP id f2mr21926585wie.6.1390433902586; Wed, 22 Jan 2014 15:38:22 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by mx.google.com with ESMTPSA id gd5sm22831632wic.0.2014.01.22.15.38.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jan 2014 15:38:19 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_6297099D-6283-4B8E-8C85-2C0C2FD3DF1E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT) From: Bob Hinden In-Reply-To: <52E05577.4070204@qti.qualcomm.com> Date: Wed, 22 Jan 2014 15:38:15 -0800 Message-Id: <8AE1D8E1-4285-4704-95E2-B22F0E5F0773@gmail.com> References: <20140122192018.8692.82071.idtracker@ietfa.amsl.com> <52E02C0C.7080901@si6networks.com> <52E0322C.1000301@qti.qualcomm.com> <52E03DCB.4060101@gont.com.ar> <52E03F1D.3000307@innovationslab.net> <47E8B622-5F85-414A-B266-87B0C998E4CD@gmail.com> <52E05292.4000301@qti.qualcomm.com> <52E05577.4070204@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1510) Cc: 6man-chairs@tools.ietf.org, Brian Haberman , ipv6@ietf.org, Bob Hinden , Fernando Gont , draft-ietf-6man-stable-privacy-addresses@tools.ietf.org, Fernando Gont , The IESG 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 23:38:26 -0000 --Apple-Mail=_6297099D-6283-4B8E-8C85-2C0C2FD3DF1E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jan 22, 2014, at 3:34 PM, Pete Resnick = wrote: > On 1/22/14 5:31 PM, Bob Hinden wrote: >> Pete, >>=20 >> On Jan 22, 2014, at 3:21 PM, Pete Resnick = wrote: >>=20 >> =20 >>> On 1/22/14 5:16 PM, Bob Hinden wrote: >>> =20 >>>> I have a question about what will happen if we agree to change it = to Informational. Will this require a new IETF last call, or sending it = back to the working group and starting the process over? >>>>=20 >>>> =20 >>> Nope. Going "down" in status just takes the wave of the IESG's magic = wand. 2026, 6.1.2, paragraph 5. >>> =20 >> Good, then I don't object. Better to get it through the process than = argue over the IETF label. >>=20 >> If there aren't objections from the w.g. then we can do that. >> =20 >=20 > But there might be objections from others on the IESG. That's why I = ABSTAINed instead of DISCUSSed. I'm not willing to stand in the way = either, even though I think the standards track outcome is not the right = one. Let us know what the IESG decides. Bob --Apple-Mail=_6297099D-6283-4B8E-8C85-2C0C2FD3DF1E 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 iQEcBAEBCgAGBQJS4FZnAAoJEK7rdBF357uoExkIAKZaidefKoTfetxl06+DJ9bz epSOY63XZH8swbxcqLFEdoeT0reGj64P/BbV8/B41ZreHpsA+8xanAlCJa6HHKdl salV70SrzWwDN24i4s96wAXod2uCfoTpZJhi+avjQtvPB00D9bxKmqFu5ms5SuFv q1OZ9zTQ9ojQpWMvZVFJK7/FTk4rblV93wwZG/iJjDOhJzKLwfuStFK418Z/+pfO Nirfo1KbkTMRnGi9vV0p2uPhMsXNksSarIzbFMkRboYjhgTC8IZQx9vyLHdUOuLI R/0BaEXtLlSKq/Hv9y7qYy/z8sOJCITxEwXnG+wXUqNfBpPVKi7yuw+X89bytSE= =OvBf -----END PGP SIGNATURE----- --Apple-Mail=_6297099D-6283-4B8E-8C85-2C0C2FD3DF1E-- From stig@venaas.com Wed Jan 22 15:41: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 95A731A0533 for ; Wed, 22 Jan 2014 15:41:16 -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 4vdW_pPk1YN9 for ; Wed, 22 Jan 2014 15:41:13 -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 EE2261A0531 for ; Wed, 22 Jan 2014 15:41:12 -0800 (PST) Received: from [10.33.12.93] (128-107-239-234.cisco.com [128.107.239.234]) by ufisa.uninett.no (Postfix) with ESMTPSA id 53DA78032; Thu, 23 Jan 2014 00:41:10 +0100 (CET) Message-ID: <52E0570D.4040403@venaas.com> Date: Wed, 22 Jan 2014 15:41:01 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.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: In-Reply-To: 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: Wed, 22 Jan 2014 23:41:16 -0000 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. > > - 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. > > 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. > > - 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. > > - (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. > > - 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. > > -- > JINMEI, Tatuya > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From otroan@employees.org Wed Jan 22 15:41: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 86BAA1A053A for ; Wed, 22 Jan 2014 15:41:27 -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, 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 OxWXlsGaHg2d for ; Wed, 22 Jan 2014 15:41:26 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 076B41A0539 for ; Wed, 22 Jan 2014 15:41:25 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAGVW4FKQ/khL/2dsb2JhbABbgwy8bYETFnSCJQEBAQMBeQULC0ZXBogQCMQpF44UaAeDJIEUBJA7mX+DLjs X-IronPort-AV: E=Sophos;i="4.95,702,1384300800"; d="asc'?scan'208";a="3366351" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 22 Jan 2014 23:41:24 +0000 Received: from dhcp-10-61-97-137.cisco.com (dhcp-10-61-97-137.cisco.com [10.61.97.137]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0MNfN47024014 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Jan 2014 23:41:24 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_C24D0E5A-E256-416D-A598-7FFAEFC055C1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Reducing the battery impact of ND From: Ole Troan In-Reply-To: <52E0423A.5070906@acm.org> Date: Thu, 23 Jan 2014 00:41:22 +0100 Message-Id: <01DC3532-C73A-4644-A323-04BE6231AADA@employees.org> References: <52D96663.6060005@sonic.net> <52DA0ABA.8030903@acm.org> <52E03BB4.8040309@acm.org> <52E0423A.5070906@acm.org> To: Erik Nordmark X-Mailer: Apple Mail (2.1827) Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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 23:41:28 -0000 --Apple-Mail=_C24D0E5A-E256-416D-A598-7FFAEFC055C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Erik, again, no hats. >> not trying to speak for Lorenzo, but I don't think he is proposing = replacing periodic RAs with periodic RSs. >=20 > Ole, >=20 > I think that is the effective result of what you two are cooking up. I cannot claim credit for cooking up that dish. aren't you proposing to do exactly that, replace periodic RAs with = periodic RSs in: draft-chakrabarti-nordmark-6man-efficient-nd >> 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). >=20 > You are speculating about some particular failure or misfeature in the = network that makes it (persistently? sometimes?) drop multicast RAs. It = would be good to flesh out that particular failure mode to see > - whether it is realistic, and > - what impact it has elsewhere. it's relatively trivial to reproduce, but I suppose you can argue that = setting timers that way is a misconfiguration. 802.11 networks are multicast challenged, so I would expect drops to be = somewhat common. a more robust RS retransmit mechanism will help that somewhat. > For instance, the failure could be that all ICMP packets to the host = are dropped (due to some misconfigured security policy - we've seen = those in IPv4). That would drop unicast RAs as well, and affect the old = path MTU discovery protocol. >=20 > Or it could be that link-local multicast is misconfigured or broken, = resulting in DNSSD and other protocols breaking. >=20 > Having every host on the planet send a RS every 30 seconds "just in = case" doesn't sound helpful. true, although it wouldn't be 'just in case'. I think you are making a = good argument that the current RS/RA mechanism is designed quite well. cheers, Ole --Apple-Mail=_C24D0E5A-E256-416D-A598-7FFAEFC055C1 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 iQEcBAEBCgAGBQJS4FcjAAoJEFuJXizso86gmxMIAISGzz+qRkMG0qptl1GU7n2a +fUuIOvuNJOpBlEayku6K5OdTh9Up0AghQjCf9aTBWR19ISDLbIjHRNiOP7ysCSt v/XTQS5H1TYn8JeLScHHwiKEfUcU4c7pXPX3TiYrlOuWPewYPfPAmfFklqUFUlP6 4CW07P+WRXfv78YXAK4mcm+ZnpDMNXvpixwjHRR4HFSeeVAYgzWowWTKjzeMSh+0 7S9nj/I9Gd/c49b2Hp7mBjbPxkst6STBGdqewCA/PZM2VGMVJOoDvSJKzN5FqcBS ePI5iwUDP22aBHPm9bVuUxY1tfImBfPtsXwGW285bizYFwkGpB2D1j5pwf2acrg= =yoYI -----END PGP SIGNATURE----- --Apple-Mail=_C24D0E5A-E256-416D-A598-7FFAEFC055C1-- From fgont@si6networks.com Wed Jan 22 15:41:52 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 85B531A053A; Wed, 22 Jan 2014 15:41: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 mBL5MSGQvYWi; Wed, 22 Jan 2014 15:41:45 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id CA2AE1A053E; Wed, 22 Jan 2014 15:41:43 -0800 (PST) Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W67QK-0006OQ-CF; Thu, 23 Jan 2014 00:41:32 +0100 Message-ID: <52E056FC.2050308@si6networks.com> Date: Wed, 22 Jan 2014 20:40:44 -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: Bob Hinden , Brian Haberman Subject: Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT) References: <20140122192018.8692.82071.idtracker@ietfa.amsl.com> <52E02C0C.7080901@si6networks.com> <52E0322C.1000301@qti.qualcomm.com> <52E03DCB.4060101@gont.com.ar> <52E03F1D.3000307@innovationslab.net> <47E8B622-5F85-414A-B266-87B0C998E4CD@gmail.com> In-Reply-To: <47E8B622-5F85-414A-B266-87B0C998E4CD@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, Pete Resnick , Dave Thaler , Fernando Gont , draft-ietf-6man-stable-privacy-addresses@tools.ietf.org, The IESG 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 23:41:52 -0000 On 01/22/2014 08:16 PM, Bob Hinden wrote: > >> And that vendor will be smacked eventually. I see Pete's point >> and I agree that this document could be Informational. >> Especially since the WG *just* adopted a document that will be >> BCP giving guidance on which IID generation mechanisms are >> preferred. >> > > While I don't think debating which IETF label to put on this > document is a very big issue as compared to the problem this draft > solves, I have a question about what will happen if we agree to > change it to Informational. We had two WGLC, two IETF LC, etc., and consensus achieved for over...two years or so. Plus plenty of documents in the same line (RFC6528, RFC6056, etc.), and the very RFCs that currently mandate to embed the hardware addresses as std track. This document states its goals, and has requirements for achieving such goals. It would be ironic (even more in the light of the perpass 2013 events) to have the "embed the hardware address" document as standard, while a privacy-enhanced document as informational (which, besides, I guess couldn't be a normative reference, or else would be a downref). Wouldn't be hard to imagine claims that "we implement the IETF standard... the other document is just informational". I guess one could debate the label... but I rather fix the problem we're meaning to solve, make progress, and if anything keep this issue in mind for the next time a similar document comes up. Just my two cents. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From stephen.farrell@cs.tcd.ie Wed Jan 22 16:10: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 642501A01D6; Wed, 22 Jan 2014 16:10:37 -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 E1HXLJikapwi; Wed, 22 Jan 2014 16:10:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D05431A0171; Wed, 22 Jan 2014 16:10:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Stephen Farrell" To: The IESG Subject: Stephen Farrell's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS and COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140123001035.19199.91573.idtracker@ietfa.amsl.com> Date: Wed, 22 Jan 2014 16:10:35 -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 00:10:37 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-6man-stable-privacy-addresses-16: Discuss 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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (0) Just modifying my disucss to discuss a part of Brian's discuss:-) I'm sure we'll sort it out easily enough though. I very much do not think that it'd be a good plan to store every address that has been generated using this algorithm. That would be making a privacy-enhancing feature damage privacy. See [1] for an example. [1] http://www.theguardian.com/technology/2011/apr/20/iphone-tracking-prompts-p= rivacy-fears (1) Section 5: Why mention only MD5 and SHA1? Why not HMAC-SHA256? 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. 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. = (*) 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. (2) Why might a sys admin want to display the secret key? 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. ---------------------------------------------------------------------- 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. 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. From alissa@cooperw.in Wed Jan 22 16:19: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 3EAD61A0116 for ; Wed, 22 Jan 2014 16:19:47 -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=unavailable 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 f__6uLDS3-mV for ; Wed, 22 Jan 2014 16:19:46 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7F31A017F for ; Wed, 22 Jan 2014 16:19:42 -0800 (PST) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id A765A208F2 for ; Wed, 22 Jan 2014 19:19:41 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Wed, 22 Jan 2014 19:19:41 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:mime-version:content-type :content-transfer-encoding; s=mesmtp; bh=PSoGJ/RkPY9xG8ZpU4AbnDM aZAA=; b=dQba18RwoQxTHOuqQif1rfY0s87SZ3vIhBk2QPPRjgVNUoR34LbcFaa 2+HB9TzbmzvcxAg13sAPpK8TYFlqLUEruKw8ZaRP+whT5qC7KORxHvGigQ+gFjZa 4LXtkXEbn+6su9DgVJYVBB+b87GayatjnpuC3eGSVe2VRr9/1C98= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :mime-version:content-type:content-transfer-encoding; s=smtpout; bh=PSoGJ/RkPY9xG8ZpU4AbnDMaZAA=; b=HG/5z4EEjzKiJd6zFmXNj+ER7sR+ dbMhwYczBszZsvfOdFiOhmXf/Zyzvz466MuMog0apZMegJDQu7uExColYp/ZFeps /v+VAM+Iic2TLTNZpiJMLLLfoc6q0KxDo11nhT2hc0HmySjYc0/7qEtmE7waGBc0 G2gWK3lTKvKQgx4= X-Sasl-enc: eRs69Kem3Jq6Ll/KaQB7guKvMMUOqBuzIdmdbg/8ArUB 1390436380 Received: from [171.68.18.48] (unknown [171.68.18.48]) by mail.messagingengine.com (Postfix) with ESMTPA id BE06BC00E87; Wed, 22 Jan 2014 19:19:37 -0500 (EST) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Wed, 22 Jan 2014 16:19:32 -0800 Subject: Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT) From: Alissa Cooper To: Bob Hinden , Pete Resnick Message-ID: Thread-Topic: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT) Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, The IESG , 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 00:19:47 -0000 (changed the subject line since Pete changed his ballot position) On 1/22/14 9:23 AM, "Bob Hinden" wrote: >Several reasons why I think Proposed Standard is appropriate. > >The properties for IPv6 interface-identifiers are defined in RFC4291, >currently at Draft Standard. This includes several types of >interface-identifiers including EUI-64 based interface-identifiers. >Other types of interface-identifers, such as temporary addresses, SEND >CGA, etc., are defined in other standards track RFCs. This document is >consistent with this. > >The working group is also working on a recommendation to make Stable >Privacy interface-identifiers the default, instead of EUI-64 based >interface-identifiers. The working group is also discussing if it wants >to deprecate the EUI-64 based interface-identifiers. See: > > >http://datatracker.ietf.org/doc/draft-gont-6man-deprecate-eui64-based-addr >esses/ Just to be clear for those in the IESG and elsewhere who may not be following this closely, there actually is not currently WG consensus to deprecate the use of EUI-64-based IIDs. So it is possible that we end up in a situation where the above-referenced draft makes SHOULD-level recommendations about which mechanisms to use or not, but no MUST-level recommendation against EUI-64-based IIDs. If draft-ietf-6man-stable-privacy-addresses is made informational, it may dilute those recommendations even further. I'm all for sticking to the document classification criteria in general, but within a specific protocol suite it makes sense to be consistent, otherwise implementers receive mixed messages merely because we don't have our own house in order. Alissa > >This is currently in an adoption call, please see the email on the >ipv6@ietf.org list. I think it would be confusing to prefer an >Informational RFC over Standards track. > >Hope this answers your question. > >Thanks, >Bob > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From tjc@ecs.soton.ac.uk Wed Jan 22 17:06: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 52E711A0111; Wed, 22 Jan 2014 17:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.756 X-Spam-Level: X-Spam-Status: No, score=-1.756 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_NEUTRAL=0.779] 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 3f8VMo-iF7VH; Wed, 22 Jan 2014 17:06:56 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD5D1A010E; Wed, 22 Jan 2014 17:06:56 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s0N16njk011802; Thu, 23 Jan 2014 01:06:49 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s0N16njk011802 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1390439209; bh=X7e2SH/Df6lOB6RXmhKGGvmZoC0=; h=From:Subject:Date:To:Mime-Version:References; b=vZ0SeTufcsmhaiT7XwFcx+D3SEBOtcqnksHJvqGyjjr1B1oGswd3/QrhBO0hV9KHp YiAvzZauRb+SLIRlrPUFFVT8cALvkXT/FrrICAOe3Ub3A0wdPw89pyRvQkPeiBJkC1 aLJzZVHI/cX0FXe4bPBMPR2NtOrq+no/fQ/BiGNo= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q0M16n0959660402Yf ret-id none; Thu, 23 Jan 2014 01:06:49 +0000 Received: from [192.168.1.108] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s0N15SSt023003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 Jan 2014 01:05:28 GMT From: Tim Chown Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: OPS-DIR review of draft-6man-stable-privacy-addresses-16 Message-ID: Date: Thu, 23 Jan 2014 01:05:28 +0000 To: ops-dir@ietf.org, draft-ietf-6man-stable-privacy-addresses.all@tools.ietf.org, 6man-chairs@tools.ietf.org, ipv6@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q0M16n095966040200; tid=q0M16n0959660402Yf; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 References: X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s0N16njk011802 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk 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 01:06:59 -0000 Hi, First, I would note that I have already contributed comments/text to = this draft, as acknowledged by Fernando. It=92s been a few versions = since I last read it. The goal of the draft has considerable merit, and I believe the document = is worthy of publication, subject to comments belwo being considered. I would classify the document as =91Ready with issues=92. Issues: 1. In the discussion in section 5 on the algorithm, it may be desirable = to suggest that implementations allow a choice of IID generation based = on =91classic=92 SLAAC with EUI-64 or via this new proposed method, with = a default of the new method. 2. In the algorithm section, there is a comment that interface names = MUST remain the same across boots or down/up events for the stable = privacy address to remain stable. I have (admittedly some time ago, and = in rare cases) seen Linux installations where network interface names = can =91swap=92, thus changing the address in use on the interface under = the proposed algorithm, whereas with existing EUI64 SLAAC the IIDs would = remain the same even if the interface name for a physical interface = changed. This is probably rather more likely if replacing a network card = on motherboard with on-board NIC(s). Perhaps Fernando can comment on = whether this is a realistic concern with modern OSes. 3. I assume the IID may/will vary for a different OS run on the same = host, e.g. where the host is dual-boot, or where a new OS installed (or = the same OS re-installed). A different OS may well use a different F(), = given that=92s not specified. With EUI-64, a dual-boot host would = likely have the same address under either OS (well, not Windows any = more=85). This may be worth making explicit. 4. The draft talks (in one place in Section 3) about stable privacy = addresses being allocated by DHCPv6; some further discussion of how this = might be achieved may be useful given the secret key is presumed to be = generated on and reside on the host, not the DHCPv6 server. Or would = this be described in a separate future draft? This may be a case where = the administrator being able to display or change the secret key needs = to be more than a MAY as currently satted in the text. 5. Design goal 1 might add =93and same interface=94 for scenarios where = a host has two interfaces in the same subnet (with the same prefix). = This scenario is one that may cause =91interesting=92 effects with = addresses if interface names swap and no Network_ID is used. 6. I=92d suggest not mentioning MD5. Nits: 1. Some references are included multiple times, e.g. [RFC4941], rather = than only at the first instance. 2. Design goal 2, perhaps say =93must=94 rather than =93do=94? 3. In section 4 the author states the goal of stable IIDs within a given = subnet. It may be better to say for a given prefix, given a renumbering = process will change the prefix and with it the IID, though by loose = language you might refer to it as the same subnet. In response to recent discussion on 6man, I don=92t believe it=92s = practical or desirable for a node to store addresses related to = locations (networks) visited. I agree with the author that the static = address per network should be generated statelessly. Tim From hannes@stressinduktion.org Wed Jan 22 17:15: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 6C2761A010C; Wed, 22 Jan 2014 17:15:17 -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, 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 f-NNr6fGRa-C; Wed, 22 Jan 2014 17:15:15 -0800 (PST) Received: from order.stressinduktion.org (order.stressinduktion.org [87.106.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id 06C521A00E7; Wed, 22 Jan 2014 17:15:14 -0800 (PST) Received: by order.stressinduktion.org (Postfix, from userid 500) id 2CB201A0C293; Thu, 23 Jan 2014 02:15:12 +0100 (CET) Date: Thu, 23 Jan 2014 02:15:12 +0100 From: Hannes Frederic Sowa To: Tim Chown Subject: Re: OPS-DIR review of draft-6man-stable-privacy-addresses-16 Message-ID: <20140123011512.GD29251@order.stressinduktion.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: 6man-chairs@tools.ietf.org, ops-dir@ietf.org, ipv6@ietf.org, draft-ietf-6man-stable-privacy-addresses.all@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 01:15:17 -0000 Hi! On Thu, Jan 23, 2014 at 01:05:28AM +0000, Tim Chown wrote: > 2. In the algorithm section, there is a comment that interface names MUST remain the same across boots or down/up events for the stable privacy address to remain stable. I have (admittedly some time ago, and in rare cases) seen Linux installations where network interface names can ‘swap’, thus changing the address in use on the interface under the proposed algorithm, whereas with existing EUI64 SLAAC the IIDs would remain the same even if the interface name for a physical interface changed. This is probably rather more likely if replacing a network card on motherboard with on-board NIC(s). Perhaps Fernando can comment on whether this is a realistic concern with modern OSes. It is mostly solved. Currently earily user space reconfigures the names of the network interface cards based on mac addresses. This also means we cannot generate those addresses while kernel boot-up but must wait until those renames have occured. For the linux implementation we are currently more and more considering a pure userspace implementation as we have problems with dad counter persistence and possible address generation algorithm configurations. > 3. I assume the IID may/will vary for a different OS run on the same host, e.g. where the host is dual-boot, or where a new OS installed (or the same OS re-installed). A different OS may well use a different F(), given that’s not specified. With EUI-64, a dual-boot host would likely have the same address under either OS (well, not Windows any more…). This may be worth making explicit. Problem here is the sharing of the secret. Well, a different OS must read the other OSes filesystem to get the secret needed for address generation. Maybe we could install those secrets into some uEFI store but I am not an expert on this. > 6. I’d suggest not mentioning MD5. Ack. Thanks, Hannes From narten@us.ibm.com Wed Jan 22 17:24: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 44D191A0200 for ; Wed, 22 Jan 2014 17:24:00 -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 WTsJOhR2wPjv for ; Wed, 22 Jan 2014 17:23:56 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id 778111A0147 for ; Wed, 22 Jan 2014 17:23:56 -0800 (PST) Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 22 Jan 2014 18:23:55 -0700 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 22 Jan 2014 18:23:54 -0700 Received: from b03cxnp07029.gho.boulder.ibm.com (b03cxnp07029.gho.boulder.ibm.com [9.17.130.16]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 22E633E4003F; Wed, 22 Jan 2014 18:23:52 -0700 (MST) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by b03cxnp07029.gho.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s0MNLQ1d7995722; Thu, 23 Jan 2014 00:21:26 +0100 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id s0N1RAgV003588; Wed, 22 Jan 2014 18:27:10 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-92-95.mts.ibm.com [9.65.92.95]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id s0N1R8HB003565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jan 2014 18:27:10 -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 s0N1NmOv031213; Wed, 22 Jan 2014 20:23:48 -0500 Date: Wed, 22 Jan 2014 20:23:48 -0500 Message-ID: From: Thomas Narten To: "Stephen Farrell" Subject: Re: Stephen Farrell's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS and COMMENT) In-Reply-To: <20140123001035.19199.91573.idtracker@ietfa.amsl.com> References: <20140123001035.19199.91573.idtracker@ietfa.amsl.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: 14012301-0928-0000-0000-000005E7606E Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, The IESG , 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 01:24:00 -0000 I have followed, but not commented on the perpass discussion. But I do share the concern raised by some that pushback as a result of perpass concerns can easily get out of hand. Is this a preview of what's to come? At Wed, 22 Jan 2014 16:10:35 -0800, Stephen Farrell wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > (0) Just modifying my disucss to discuss a part of Brian's discuss:-) > I'm sure we'll sort it out easily enough though. I very much do not > think that it'd be a good plan to store every address that has been > generated using this algorithm. That would be making a > privacy-enhancing feature damage privacy. See [1] for an example. And can you point me to the text in the draft that suggests doing so? (Hint: the draft says no such thing.) Or for that mattter, who has suggested anyone do this? (Again, AFAIK, no one has suggested this.) Are we in hyperbole land? Can we please get back to reality? Are we now going to require that all internal logs be scrubbed of potentially sensitive material? If we think we are going to stop the storage and recording of IP addresses on the devices that are actually using those addresses, that is just nuts. Think this through for a minute! I'm sure the IETF could say the IP stack (as part of trying to make network connectivity work better) shouldn't store/cache addresses it has used. And maybe as a result the stack will work a little less efficiently but it at least won't have stored an address it recently used... But then we better hope that noone bothers to look in the browser cache, or /var/log/messages, etc. which will likely have the same information and much much more... Thomas From stephen.farrell@cs.tcd.ie Wed Jan 22 17:37: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 080DE1A0343; Wed, 22 Jan 2014 17:37:36 -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, 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 2Vp5vUS7atXb; Wed, 22 Jan 2014 17:37:33 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 038CE1A01B7; Wed, 22 Jan 2014 17:37:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7372DBE47; Thu, 23 Jan 2014 01:37:31 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pu4JF+9ndLIq; Thu, 23 Jan 2014 01:37:30 +0000 (GMT) Received: from [10.87.48.3] (unknown [86.44.74.137]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 28E3ABE39; Thu, 23 Jan 2014 01:37:30 +0000 (GMT) Message-ID: <52E07259.9050902@cs.tcd.ie> Date: Thu, 23 Jan 2014 01:37:29 +0000 From: Stephen Farrell 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: Stephen Farrell's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS and COMMENT) References: <20140123001035.19199.91573.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, The IESG , 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 01:37:36 -0000 On 01/23/2014 01:23 AM, Thomas Narten wrote: > I have followed, but not commented on the perpass discussion. But I do > share the concern raised by some that pushback as a result of perpass > concerns can easily get out of hand. > > Is this a preview of what's to come? No. Nothing is out of hand. I asked to discuss Brian's discuss. > > At Wed, 22 Jan 2014 16:10:35 -0800, > Stephen Farrell wrote: >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> (0) Just modifying my disucss to discuss a part of Brian's discuss:-) >> I'm sure we'll sort it out easily enough though. I very much do not >> think that it'd be a good plan to store every address that has been >> generated using this algorithm. That would be making a >> privacy-enhancing feature damage privacy. See [1] for an example. > > And can you point me to the text in the draft that suggests doing so? > (Hint: the draft says no such thing.) No. And I clearly said that. "to discuss a part of Brian's discuss" clearly indicates that I am not saying that the draft says that. > Or for that mattter, who has suggested anyone do this? (Again, AFAIK, > no one has suggested this.) See Brian's discuss. If that's not what he meant (and I know the draft author also thinks it was) then it won't be a problem. If it is, we'll discuss it briefly and sort it out. I'll skip the text below. I'm sorry you're upset, but frankly I don't think your upset is at all justified. S. > > Are we in hyperbole land? Can we please get back to reality? > > Are we now going to require that all internal logs be scrubbed of > potentially sensitive material? If we think we are going to stop the > storage and recording of IP addresses on the devices that are actually > using those addresses, that is just nuts. Think this through for a > minute! > > I'm sure the IETF could say the IP stack (as part of trying to make > network connectivity work better) shouldn't store/cache addresses it > has used. And maybe as a result the stack will work a little less > efficiently but it at least won't have stored an address it recently > used... > > But then we better hope that noone bothers to look in the browser > cache, or /var/log/messages, etc. which will likely have the same > information and much much more... > > Thomas > From narten@us.ibm.com Wed Jan 22 18:07: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 BB5E61A01D6 for ; Wed, 22 Jan 2014 18:07:47 -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=unavailable 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 WQX4kiyDFTrH for ; Wed, 22 Jan 2014 18:07:46 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by ietfa.amsl.com (Postfix) with ESMTP id 0F53F1A017F for ; Wed, 22 Jan 2014 18:07:46 -0800 (PST) Received: from /spool/local by e33.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 22 Jan 2014 19:07:45 -0700 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e33.co.us.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 22 Jan 2014 19:07:43 -0700 Received: from b03cxnp07029.gho.boulder.ibm.com (b03cxnp07029.gho.boulder.ibm.com [9.17.130.16]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id A302B1FF001A; Wed, 22 Jan 2014 19:07:10 -0700 (MST) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by b03cxnp07029.gho.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s0N05G5e8978942; Thu, 23 Jan 2014 01:05:16 +0100 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s0N27gZl028243; Wed, 22 Jan 2014 19:07:42 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-92-95.mts.ibm.com [9.65.92.95]) by d03av04.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s0N27fDO028140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jan 2014 19:07:42 -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 s0N27cLE005160; Wed, 22 Jan 2014 21:07:38 -0500 Date: Wed, 22 Jan 2014 21:07:38 -0500 Message-ID: From: Thomas Narten To: "Pete Resnick" Subject: Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT) In-Reply-To: <20140122192018.8692.82071.idtracker@ietfa.amsl.com> References: <20140122192018.8692.82071.idtracker@ietfa.amsl.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: 14012302-0928-0000-0000-000005A81F65 Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, The IESG , 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 02:07:47 -0000 Hi Pete. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- Glad this is only a comment, but I think if one argues this document shouldn't be PS, it opens up the door to saying a rather substantial number of the standards the IETF has produced in the past should not be on standards track either. I think its worth noting that the classifications we have (standard/info/bcp/applicability statements) have a very course granularity. There are lots of individual "things" that don't fit cleanly into exactly one category, if you start looking closely. For example, the IETF doesn't really (usually) produce informational documents that people go off and implement. If you are going to code something, then presumably you want all implementations do things in a certain way (so they exhibit important behavior). And you want to be able to verify that implementations were able to implement from the spec (perhaps using MUST/SHOULD type language - or perhaps not). We get that with standards track documents. We have no mechanism in our processes for reviewing Informational RFCs and whether they were implementable and meet our criteria for being called a standard. Isn't that one of the core reasons the IETF exists? Thus, for IETF WGs, I would say that the vast majority of stuff that is produced that describes an implementation should be on standards track. This document fits squarely in that category. > This is an algorithm to generate stable, private, and mostly unique > addresses. It does not affect interoperability at all if people choose > a different method. Sure it may. If we want the IETF "standard" to be "generate addresses however you want, hopefully they will work, but it's not the business of an IETF standard to tell you how to ensure you are doing things right", then I guess publishing this document as informational (and giving it the same status as an RFC such as "FooBar's Proprietary Protocol") would be the way to go. But be careful what you wish for. I'm pretty sure the IPv6 addressing architecture shouldn't be on standards track per your argument. And maybe the original SLAAC spec shouldn't be either. Beware the slippery slope. > Anyone can accomplish the same task in a number of > different ways. This is just a nice method to use if someone wanted to > use it. This should just be an Informational document explaining a > nice way to generate stable, private, mostly unique addresses without > all of the MUSTs and SHOULDs, which are not interoperability > requirements in the first place. Standardizing this is silly in the > extreme. Others have commented on this, but it is perfectly fine (and has been in the IETF for a long time) to use MUST/MAY type language in informational documents. Especially ones that describe protocol details. Why bring up this Red Herring? Thomas From fgont@si6networks.com Thu Jan 23 01:19: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 AB6221A0342; Thu, 23 Jan 2014 01:19:08 -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 JoH_JG6EojfF; Thu, 23 Jan 2014 01:19:04 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 77E411A033E; Thu, 23 Jan 2014 01:19:04 -0800 (PST) Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W6GQk-0004PR-F0; Thu, 23 Jan 2014 10:18:34 +0100 Message-ID: <52E0C6A8.3050503@si6networks.com> Date: Thu, 23 Jan 2014 04:37:12 -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: Tim Chown , ops-dir@ietf.org, draft-ietf-6man-stable-privacy-addresses.all@tools.ietf.org, 6man-chairs@tools.ietf.org, ipv6@ietf.org Subject: Re: OPS-DIR review of draft-6man-stable-privacy-addresses-16 References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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 09:19:09 -0000 Hi, Tim, Thanks so much for your feedback! Please find my comments in-line... On 01/22/2014 10:05 PM, Tim Chown wrote: > Issues: > > 1. In the discussion in section 5 on the algorithm, it may be > desirable to suggest that implementations allow a choice of IID > generation based on ‘classic’ SLAAC with EUI-64 or via this new > proposed method, with a default of the new method. This point is actually addressed by the draft-ietf version for deprecate-eui64 (which will not deprecate eui64, but will specify the default). i.e., this document just focuses on how you implement stable-privacy. The draft-ietf version of deprecate-eui64 (draft-ietf-6man-ipv6-defult-iids) seems like the place to specify that of having a knob to configure which method to use... > 2. In the algorithm section, there is a comment that interface names > MUST remain the same across boots or down/up events for the stable > privacy address to remain stable. Strictly speaking, it says that Net_Iface MUST be constant. Then Appendix A discusses possible sources for NetIface... > I have (admittedly some time ago, > and in rare cases) seen Linux installations where network interface > names can ‘swap’, thus changing the address in use on the interface > under the proposed algorithm, whereas with existing EUI64 SLAAC the > IIDs would remain the same even if the interface name for a physical > interface changed. This is probably rather more likely if replacing a > network card on motherboard with on-board NIC(s). Perhaps Fernando > can comment on whether this is a realistic concern with modern OSes. I think I was told that this has been fixed in Linux . That said, we don't require any specific source for NetIface. For instance, you can even use the link-layer address (please see Section A.3), such that you get the same stability properties as EUI64 SLAAC. The rationale for not requiring any specific source is that an implementer know better which source is more stable/convenient. Some source might be stable in one OS, but not in others. And viceversa. > 3. I assume the IID may/will vary for a different OS run on the same > host, e.g. where the host is dual-boot, or where a new OS installed > (or the same OS re-installed). A different OS may well use a > different F(), given that’s not specified. With EUI-64, a dual-boot > host would likely have the same address under either OS (well, not > Windows any more…). This may be worth making explicit. This could be a pro or con, one might say. I guess we could add something along the lines of: "Since different implementation are likely to use different values for secret_key, and may also employ different PRNGs for F() and different surces for NetIface, we note that an a host that is dual-boot or that is reinstalled may result in different IPv6 addresses for each OS and/or installation."? > 4. The draft talks (in one place in Section 3) about stable privacy > addresses being allocated by DHCPv6; some further discussion of how > this might be achieved may be useful given the secret key is presumed > to be generated on and reside on the host, not the DHCPv6 server. Or > would this be described in a separate future draft? Yes, a future draft -- e.g. where the algorithm is computed by the DHCPv6 server. > 5. Design goal 1 might add “and same interface” for scenarios where a > host has two interfaces in the same subnet (with the same prefix). > This scenario is one that may cause ‘interesting’ effects with > addresses if interface names swap and no Network_ID is used. Will do. (the seconds sentence already notes this). > 6. I’d suggest not mentioning MD5. Yep. Will do. > Nits: > > 1. Some references are included multiple times, e.g. [RFC4941], > rather than only at the first instance. I will check this -- it could be that I'm referring to different terms of the same specs.... or just me being plain redundant. :-( > 2. Design goal 2, perhaps say “must” rather than “do”? Yep. Will do. > 3. In section 4 the author states the goal of stable IIDs within a > given subnet. It may be better to say for a given prefix, given a > renumbering process will change the prefix and with it the IID, > though by loose language you might refer to it as the same subnet. Will do. > In response to recent discussion on 6man, I don’t believe it’s > practical or desirable for a node to store addresses related to > locations (networks) visited. I agree with the author that the > static address per network should be generated statelessly. Great. :-) Thanks so much! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Thu Jan 23 01: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 D97941A0353 for ; Thu, 23 Jan 2014 01: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 1Y94cInDZp8c for ; Thu, 23 Jan 2014 01: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 9FAA41A033E for ; Thu, 23 Jan 2014 01:19:14 -0800 (PST) Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W6GQt-0004PV-Ng; Thu, 23 Jan 2014 10:18:44 +0100 Message-ID: <52E0D289.9040501@si6networks.com> Date: Thu, 23 Jan 2014 05:27: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: Thomas Narten , ipv6@ietf.org Subject: Re: Review of draft-ietf-6man-stable-privacy-addresses-16.txt 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: Thu, 23 Jan 2014 09:19:18 -0000 Hi, Thomas, Thanks so much for your detailed feedback! -- Please find my responses in-line... On 01/22/2014 03:36 PM, Thomas Narten wrote: > > First, I'm surprised this document doesn't reference any of the DNA > work (RFC 4436 & 6059). That work is all about determining whether > you've attached to the same network as one you've attached to before > and reusing the same network parameters if you do. Given that this > document is about using the same IID when connecting to the same > network... This seems like an oversight. I.e., shouldn't some of the > same approaches for determining what network you are on be leveraged? I'm not sure whether you're arguing: 1) That one might employ DNA to obtain a Network_ID for the expression in this document, or, 2) That one might do DNA before actually trying to compute the IID with this document. I'm fine with 2), but think that 1) is rather orthogonal to this I-D. (please see below regarding one proposal to achive "2)") > Two things come to mind. If you have stable storage (and many devices > do), it makes sense to just cache the addresses instead of > regenerating them. This seems to be out of the scope of this document. Additionally, this might make sense for some device that you move among a limited set of networks. But I bet that in most of our cases, we travel from one place to another, and not infrequently use networks only once in our devices' lifetime. > DNA does this. Seems like that option should be > allowed. (the current document suggests saving the number of DAD > iterations in stable storage... why do that if you can just save the > address itself?) I don't expect nodes to implement the "save the DAD counter" part. -- For instance, that's why it's a "MAY", rather than a SHOULD or MUST. That said, the reason for saving the DAD counter (as opposed to the whole address) is that the address that you've saved might collide when you reuse it. If you save the DAD counter, eventually you'll have a DAD counter that results in an address that never collides with anything... and hence you always use such address. > For the wired case (i.e, no SSID), DNA suggests > using the linklayer/linklocal address pair of routers to identify a > link. This document might suggest doing the same thing. I don't think tying network identification to the router's link-layer or link-local address is a good idea. For instance, there's no reason why a NIC replacement at the router or a backup router coming to life should result in a different address. Note that the different goals in DNA and this allows this approach to be more lightweight, so to speak. > Seems this spec might benefit from a clearer applicability > statement. There seem to be two motivations for the document: 1) > mitigate off-site scanning attacks and 2) making it harder to track > devices that move. This document: (referenced in this I-D) provides a more thorough explanation. (at the time the wg decided that a thorough discussion deserved it's own document). > The second item seems of interest (only) to personally owned devices, > those that are typically owned by a single user and are (at least > somewhat) mobile. For other types of devices (e.g., those typically > found in data centers), I suspect this motivation is not compelling. > I think it would be good to make this more clear. > > On mitigating address scanning attacks, that will be of interest to > some folk. But I suspect there are others that won't care all that > much. There are other issues, such as device-specific vulnerability exploitation, etc. Bottom-line is that you want to fail on the safe side. And if you some some specific reason for using IIDs that embed hardware addresses, override the more sane default in your specific case. > Finally, I want to raise a generic issue that applies to this > document, but really is a general problem. The document adds a random > delay between 0 and IDGEN_DELAY in order to avoid lock-step > behavior. While that is a good thing, Using IDGEN_DELAY of 1 second is > pretty long for some network technologies (think data center with 10G > or higher interfaces). I wonder if we should stop using constants that > are fixed and make them more dependent on actual network > technology. E.g., 1 second seems OK for WiFi, but not for 10G. As noted in a separate email, we're talking about collisions of 64-bit random numbers. The odds of that are pretty low. And if that happens, let's say that an average delay of 0.5 sec would not be a big deal. Put another way: I understand your concern, and mostly agree with your view. But for this specific case, even something like an IDGEN_DELAY of 5 would be fine, since the odds of having to actually use such delay are almost nil. > Likewise, should you ever stop trying to configure an address if you > keep getting DAD failures? I'm of two minds. Going forward, it becomes > increasingly painful to require operator intervention to "fix" > something that isn't working. That argues for never giving up. But > what should happen then is some sort of exponential backoff should be > used to ensure that retries happen infrequently, so as not to cause > network problems. The current text says: > >> We also >> note that hosts MUST limit the number of tentative addresses that are >> tried (rather than indefinitely try a new tentative address until the >> conflict is resolved). > > But that is pretty vague advice. It's kind of intended. Again, in this case /64-bit subnetworks) collisions are so unlikely that you're probably already good enough without even retrying after a collision. The odds of the same node finding, say, 2 or 3 collisions in a row are extremely low. > That all said, if you have a device with a (broken) implementation, > having it try over and over again makes no sense either. > > Editorial comments: > >> However, implementations conforming to >> this specification MAY employ the algorithm specified in [RFC4941] to >> generate temporary addresses in addition to the addresses generated >> with the algorithm specified in this document. > > reword to say something like "MAY employ other alogorithms for > generating additional temporary addresses (e.g., RFC4941])." > > The MAY should make it clear that other approaches are allowed, with > 4941 being one example. Rather than suggesting only that RFC4941 MAY > be implemented. The goal here was to be clear what we were referring to. So far the only algorithm specified for generating temp addresses is RFC4941. And we though it would be more clear to refer to it explicitly (particularly when we have found that terminology on the subject is not that clear/well-defined). > Network_ID: > Some network specific data that identifies the subnet to which > this interface is attached. For example the IEEE 802.11 > Service Set Identifier (SSID) corresponding to the network to > which this interface is associated. This parameter is > OPTIONAL. > > RFC6059 (DNAv6) may be useful here. It has the notion of identifying a > link by a combination of the routers Link-local + Link Layer > address. How about adding something along the lines of: "DNAv6 [RFC6059] could be employed to obtain a Network_ID to be employed for this parameter" ? > > Local Addresses (ULAs). In those scenarios where the Network_ID is > unknown to the attacker, including this parameter might help mitigate > attacks where a victim node connects to the same subnet as the > attacker, and the attacker tries to learn the Interface Identifier > used by the victim node for a remote network (see Section 9 for > further details). > > add reference to ULAs on first use of term. Oops, you're right. > Finally, we note that all of the bits in the resulting Interface IDs > are treated as "opaque" bits [I-D.ietf-6man-ug]. For example, the > universal/local bit of Modified EUI-64 format identifiers is treated > as any other bit of such identifier. In theory, this might result in > Duplicate Address Detection (DAD) failures that would otherwise not > be encountered. However, this is not deemed as a real issue, because > of the following considerations: > > Wording is awkward about DAD failures...wording suggests the problem > is DAD. Actually, the problem is that failures lead to duplicate > addresses -- that is the real issue. That DAD catches them is a good > thing. > > NEW TEXT: > > In theory, this might result in address formation collisions and > Duplicate Address Detection (DAD) failures that would otherwise not > be encountered. However, this is not deemed as a real issue, because > of the following considerations: > > also, s/real issue/likely issue/ > > It will be a very "real" issue when it happens, e.g., as it likely > will when implementations mess up! Thanks for the help with improving the text. I will incorporate your suggested text. > o Since some popular and widely-deployed operating systems (such as > Microsoft Windows) do not employ unique hardware addresses for the > Interface IDs of their stable addresses, reliance on such unique > identifiers is more reduced in the deployed world (fewer deployed > systems rely on them for the avoidance of address collisions). > > wording is awkward. what are "unique hardware addresses"? Do you mean > standard SLAAC? I should remove "unique". The point is that Windows does not employ hardware addresses for the IIDs (i., they do not employ standard SLAAC). > Also, what are you trying to say above? that because windows doesn't > do SLAAC, and things didn't break, something isn't an issue? That's not > much of a justification, and should maybe just be deleted. What I'm saying is: 1) Of the installed base, not all systems are potentially affected by this -- not the Microsoft ones, at least. 2) OTOH, uniqueness based on the hardware addresses cannot relied upon anyway, since research indicates that they are largely duplicated. > This procedure may be repeated a number of times until the address > conflict is resolved. Hosts SHOULD try at least IDGEN_RETRIES (see > Section 7) tentative addresses if DAD fails for successive generated > addresses, in the hopes of resolving the address conflict. We also > note that hosts MUST limit the number of tentative addresses that are > tried (rather than indefinitely try a new tentative address until the > conflict is resolved). > > wonder if it would be better to specify some rate limiting that makes > sense. Isn't that somewhat implicitly specified in the random delay that nodes need to wait before retrying? > In those unlikely scenarios in which duplicate addresses are detected > and in which the order in which the conflicting nodes configure their > addresses may vary (e.g., because they may be bootstrapped in > different order), the algorithm specified in this section for > resolving DAD conflicts could lead to addresses that are not stable > within the same subnet. In order to mitigate this potential problem, > nodes MAY record the DAD_Counter value employed for a specific > {Prefix, Net_Iface, Network_ID} tuple in non-volatile memory, such > that the same DAD_Counter value is employed when configuring an > address for the same Prefix and subnet at any other point in time. > > if you have non-volatle memory, wouldn't it just make more sense to > save the address you generated before? I.e., that is what DNA does... If you just store the address, and there are address collisions, there might be oscillations wrt which address each node uses (depending on the order in which each node is bootstrapped). OTOH, if you store the DAD counter, eventually each node will converge to a stable address. > In the event that a DAD conflict cannot be solved (possibly after > trying a number of different addresses), address configuration would > fail. In those scenarios, nodes MUST NOT automatically fall back to > employing other algorithms for generating Interface Identifiers. > > why not? Because if you are employing this scheme, you don't want your address to leak your device identity. I'd note that the only scenario in which I could envision multiple collisions in a row from random numbers is that in which an attacker is actively messing up with DAD. > Hosts SHOULD introduce a random delay between 0 and IDGEN_DELAY > seconds (see Section 7) before trying a new tentative address, to > avoid lock-step behavior of multiple hosts. > > IDGEN_DELAY of 1 sec is too long for some network technologies. Yes, but the average is 0.5, and the odds of actually having to use it is *extremely* small (we're talking about collisions within a 64-bit space). Even then, you can go against the SHOULD if you have a good reason to. > Need to put in a reference to ULA spec. Will do. Thanks so much! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From bclaise@cisco.com Thu Jan 23 01:21: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 80F381A0342; Thu, 23 Jan 2014 01:21:09 -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 5l7K63aIbNLL; Thu, 23 Jan 2014 01:21:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 741AD1A034D; Thu, 23 Jan 2014 01:21:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Benoit Claise" To: The IESG Subject: Benoit Claise's 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: <20140123092102.22697.55292.idtracker@ietfa.amsl.com> Date: Thu, 23 Jan 2014 01:21:02 -0800 Cc: 6man-chairs@tools.ietf.org, tjc@ecs.soton.ac.uk, 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 09:21:09 -0000 Benoit Claise 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: ---------------------------------------------------------------------- Please Tim's OPS DIR review (currently under discussion) First, I would note that I have already contributed comments/text to this draft, as acknowledged by Fernando. It=E2=80=99s been a few versions since= I last read it. The goal of the draft has considerable merit, and I believe the document is worthy of publication, subject to comments belwo being considered. I would classify the document as =E2=80=98Ready with issues=E2=80=99. Issues: 1. In the discussion in section 5 on the algorithm, it may be desirable to suggest that implementations allow a choice of IID generation based on =E2=80=98classic=E2=80=99 SLAAC with EUI-64 or via this new proposed method= , with a default of the new method. 2. In the algorithm section, there is a comment that interface names MUST remain the same across boots or down/up events for the stable privacy address to remain stable. I have (admittedly some time ago, and in rare cases) seen Linux installations where network interface names can =E2=80=98= swap=E2=80=99, thus changing the address in use on the interface under the proposed algorithm, whereas with existing EUI64 SLAAC the IIDs would remain the same even if the interface name for a physical interface changed. This is probably rather more likely if replacing a network card on motherboard with on-board NIC(s). Perhaps Fernando can comment on whether this is a realistic concern with modern OSes. 3. I assume the IID may/will vary for a different OS run on the same host, e.g. where the host is dual-boot, or where a new OS installed (or the same OS re-installed). A different OS may well use a different F(), given that=E2=80=99s not specified. With EUI-64, a dual-boot host would li= kely have the same address under either OS (well, not Windows any more=E2=80=A6)= . = This may be worth making explicit. 4. The draft talks (in one place in Section 3) about stable privacy addresses being allocated by DHCPv6; some further discussion of how this might be achieved may be useful given the secret key is presumed to be generated on and reside on the host, not the DHCPv6 server. Or would this be described in a separate future draft? This may be a case where the administrator being able to display or change the secret key needs to be more than a MAY as currently satted in the text. 5. Design goal 1 might add =E2=80=9Cand same interface=E2=80=9D for scenari= os where a host has two interfaces in the same subnet (with the same prefix). This scenario is one that may cause =E2=80=98interesting=E2=80=99 effects with a= ddresses if interface names swap and no Network_ID is used. 6. I=E2=80=99d suggest not mentioning MD5. Nits: 1. Some references are included multiple times, e.g. [RFC4941], rather than only at the first instance. 2. Design goal 2, perhaps say =E2=80=9Cmust=E2=80=9D rather than =E2=80=9Cd= o=E2=80=9D? 3. In section 4 the author states the goal of stable IIDs within a given subnet. It may be better to say for a given prefix, given a renumbering process will change the prefix and with it the IID, though by loose language you might refer to it as the same subnet. In response to recent discussion on 6man, I don=E2=80=99t believe it=E2=80= =99s practical or desirable for a node to store addresses related to locations (networks) visited. I agree with the author that the static address per network should be generated statelessly. From brian@innovationslab.net Thu Jan 23 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 E432B1A041B; Thu, 23 Jan 2014 03:37:17 -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 lYqO-clwtSP7; Thu, 23 Jan 2014 03:37:16 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5E51A03DF; Thu, 23 Jan 2014 03:37:16 -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 6CC68880F3; Thu, 23 Jan 2014 03:37:15 -0800 (PST) Received: from clemson.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 8C2C6130003; Thu, 23 Jan 2014 03:37:14 -0800 (PST) Message-ID: <52E0FEEA.7020105@innovationslab.net> Date: Thu, 23 Jan 2014 06:37:14 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stephen Farrell , Fernando Gont , The IESG Subject: Re: Brian Haberman's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS) References: <20140122202434.30069.4084.idtracker@ietfa.amsl.com> <52E02EAD.1050009@si6networks.com> <52E03BAD.5050306@innovationslab.net> <52E046B0.1000701@cs.tcd.ie> In-Reply-To: <52E046B0.1000701@cs.tcd.ie> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qGfUADDRJviqHSBIBXBrHTgrXwxh0TUDs" 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 11:37:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qGfUADDRJviqHSBIBXBrHTgrXwxh0TUDs Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/22/14 5:31 PM, Stephen Farrell wrote: >=20 >=20 > On 01/22/2014 09:44 PM, Brian Haberman wrote: >>>> 1) Recording the addresses a node has visited during its >>>> lifetime would somehow be ironic for a document aiming at >>>> privacy. Just get the document compromised, and you get a list >>>> of where the node has been since it was first installed. >> I think I can get a list of where a device has been from any number >> of places. So, I don't buy that argument at all. >=20 >=20 > I buy the argument. Some vendors have been beaten up for > it now and then. Making that worse while trying to make > privacy better would be a shame, no? >=20 > S. >=20 > [1] > http://www.theguardian.com/technology/2011/apr/20/iphone-tracking-promp= ts-privacy-fears >=20 Duly noted. If that is a concern, then it should be noted in the draft that storing the address is a bad idea. That way, people won't be tempted to implement this feature in that way. Regards, Brian --qGfUADDRJviqHSBIBXBrHTgrXwxh0TUDs 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 iQEcBAEBCgAGBQJS4P7qAAoJEBOZRqCi7goq7scIALDwskBugnn2npSzScE7cDFR KsQmDWK+RRzF9DaleHjp+L2LxbwVzVdiTBbVwtDICcSTuY6lul5Rq1s1dJBEz32j /IzcacZNHuiCyq9MWz6WhyBpaOS5ofwbTeLTM8WC/Tn7YNSEaijmeza9SgSSfG3p /1eWiL1QZ74oscGIkxZdQmXAfmcMwGgjGAbhbAgQK8gGg9pi+YjmjzdjPUHTx6OT JN75wl74vlQcZcFu69n4Smt03yvjk6dvkyrHoMV7bCzZqKngVkGT06oFVfq39CqJ OXK9TGtQX4ZqdGaf/6LSSFD7GErC1svLtckq0BBh633ngbE5I6u5FAnRsdzbGcE= =96Ip -----END PGP SIGNATURE----- --qGfUADDRJviqHSBIBXBrHTgrXwxh0TUDs-- From brian@innovationslab.net Thu Jan 23 03:39: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 2B5471A044D; Thu, 23 Jan 2014 03:39:15 -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 emGr1G9Kqqd2; Thu, 23 Jan 2014 03:39:10 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 50FC01A041B; Thu, 23 Jan 2014 03:39:10 -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 B5A6F880F3; Thu, 23 Jan 2014 03:39:09 -0800 (PST) Received: from clemson.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 D93C6130003; Thu, 23 Jan 2014 03:39:08 -0800 (PST) Message-ID: <52E0FF5C.8050906@innovationslab.net> Date: Thu, 23 Jan 2014 06:39:08 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Fernando Gont , Fernando Gont , The IESG Subject: Re: Brian Haberman's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS) References: <20140122202434.30069.4084.idtracker@ietfa.amsl.com> <52E02EAD.1050009@si6networks.com> <52E03BAD.5050306@innovationslab.net> <52E04278.1000401@gont.com.ar> In-Reply-To: <52E04278.1000401@gont.com.ar> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="80tkKUGtRGUSkRjsfooqStdU5eqIfLNKu" 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 11:39:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --80tkKUGtRGUSkRjsfooqStdU5eqIfLNKu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/22/14 5:13 PM, Fernando Gont wrote: >> All this point is making is that there are a variety of ways of >> getting this behavior and DNA provided guidance on one way to do=20 >> that. The simple solution is to refer to those RFCs >> (informatively) and point out that they describe one way to track >> which addresses are associated with particular networks. This has >> the benefit of not forcing re-calculation of the hash on every >> (re-)connect. >=20 > I have no issues with that (I misinterpreted where you were going, it > seems). >=20 > So I guess one could add something along the lines of: > "A node may use Simple DNA [RFC6059] to reuse a previously-configured > address for this network without the need to recompute the > Interface-ID with the scheme specified in this document." >=20 > ? >=20 That would work for me. We can wait to see if any of AD has an issue with this text. Regards, Brian --80tkKUGtRGUSkRjsfooqStdU5eqIfLNKu 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 iQEcBAEBCgAGBQJS4P9cAAoJEBOZRqCi7goqOWUIAMa+t0rhjmrazUWTP+jkWJQ9 vUC8fPwWA1xLm0mDXb0GgE+7OAmM5essVTNFR3bTSwRWURqHZm3StX3meh6SnlIU NXZAWsrh4jjF+fTaSzfraTT1K+ITo3VrMw+4cA2APBnbDwK5VpSTmevfbV/byEMP tg4+ummYzZ2ZviD7a9oOZZC9CKtD28BG/Hgl9z3mdaTSOHhafcQFn9UMjfycOPQA ymbw40LpWBU2Ypu1UBo3O4/h2pvU8eFPrSfYQkZZbJMlQdwJhQC94egnyUbIrPiw Xr1B5k1oRP7nRnRcSiU4Hsp2k2cHwl+u0j6S359hm6bHEqyV8ApFHrWUsQVMLCk= =lrmU -----END PGP SIGNATURE----- --80tkKUGtRGUSkRjsfooqStdU5eqIfLNKu-- From brian@innovationslab.net Thu Jan 23 03:44: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 CC3001A03E0; Thu, 23 Jan 2014 03:44:33 -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 GrI1OUYyQBny; Thu, 23 Jan 2014 03:44:32 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9A59A1A03E9; Thu, 23 Jan 2014 03:44:32 -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 0565A880F3; Thu, 23 Jan 2014 03:44:32 -0800 (PST) Received: from clemson.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 21E7D130003; Thu, 23 Jan 2014 03:44:31 -0800 (PST) Message-ID: <52E1009F.2040104@innovationslab.net> Date: Thu, 23 Jan 2014 06:44:31 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Benoit Claise , The IESG Subject: Re: Benoit Claise's No Objection on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT) References: <20140123092102.22697.55292.idtracker@ietfa.amsl.com> In-Reply-To: <20140123092102.22697.55292.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FJ3lAM1mXx3gPxXIhxp2A4U7VeXd45R5d" Cc: 6man-chairs@tools.ietf.org, tjc@ecs.soton.ac.uk, 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 11:44:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FJ3lAM1mXx3gPxXIhxp2A4U7VeXd45R5d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Tim & Benoit, On 1/23/14 4:21 AM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > draft-ietf-6man-stable-privacy-addresses-16: No Objection >=20 > 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.) >=20 >=20 > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.htm= l > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresse= s/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Please Tim's OPS DIR review (currently under discussion) >=20 > First, I would note that I have already contributed comments/text to th= is > draft, as acknowledged by Fernando. It=92s been a few versions since I= > last read it. >=20 > The goal of the draft has considerable merit, and I believe the documen= t > is worthy of publication, subject to comments belwo being considered. >=20 > I would classify the document as =91Ready with issues=92. >=20 > Issues: >=20 > 1. In the discussion in section 5 on the algorithm, it may be desirable= > to suggest that implementations allow a choice of IID generation based = on > =91classic=92 SLAAC with EUI-64 or via this new proposed method, with a= > default of the new method. >=20 Actually, this preference is out of scope for this document. There is a BCP in the works within 6MAN that will describe the current thinking on which IID-generation mechanisms should be preferred. Regards, Brian --FJ3lAM1mXx3gPxXIhxp2A4U7VeXd45R5d 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 iQEcBAEBCgAGBQJS4QCfAAoJEBOZRqCi7goqjX8IALJsti5EOP5oPYAQcbqhtyUH lfTpCOwmr3Ps14erfEb7NSHfMF9a/j5SzZsn+be+j5rheONnrHASR8hssmaMVQHE nMpnZj4W+IXtf54tpIXbH+CYmGwMGgVwu5yoZD2mu8lh1qLe5TQVSWxuZZ8h5fBF CHCUYgA9m6dtD40UvF1KS14b2kPuKF2pA7AtM7SvgS9y7QBNLeaoNRNDLhStgfKj VEI3RKH1e3B3CnU+YtlNfUr4scHP8iO/OmbKLKRkyYGDVqEU57t4kF02DC+VFcFk YgafUEQ59pE6rzAp21RAz2bFdm4S+eCFYWLYVW9DcxyDV60VhNF9dhwZGWEMbYE= =Z+vv -----END PGP SIGNATURE----- --FJ3lAM1mXx3gPxXIhxp2A4U7VeXd45R5d-- From stephen.farrell@cs.tcd.ie Thu Jan 23 03: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 B835A1A03E6; Thu, 23 Jan 2014 03:45:12 -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, 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 6RGO2VXodkth; Thu, 23 Jan 2014 03:45:11 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9318D1A03E0; Thu, 23 Jan 2014 03:45:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 61C2FBE39; Thu, 23 Jan 2014 11:45:10 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUsMV+xjxux9; Thu, 23 Jan 2014 11:45:08 +0000 (GMT) Received: from [10.87.48.3] (unknown [86.45.63.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A239ABE38; Thu, 23 Jan 2014 11:45:08 +0000 (GMT) Message-ID: <52E100C4.4070406@cs.tcd.ie> Date: Thu, 23 Jan 2014 11:45:08 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Brian Haberman , Fernando Gont , The IESG Subject: Re: Brian Haberman's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS) References: <20140122202434.30069.4084.idtracker@ietfa.amsl.com> <52E02EAD.1050009@si6networks.com> <52E03BAD.5050306@innovationslab.net> <52E046B0.1000701@cs.tcd.ie> <52E0FEEA.7020105@innovationslab.net> In-Reply-To: <52E0FEEA.7020105@innovationslab.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 11:45:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/23/2014 11:37 AM, Brian Haberman wrote: > > > On 1/22/14 5:31 PM, Stephen Farrell wrote: >> >> >> On 01/22/2014 09:44 PM, Brian Haberman wrote: >>>>> 1) Recording the addresses a node has visited during its >>>>> lifetime would somehow be ironic for a document aiming at >>>>> privacy. Just get the document compromised, and you get a >>>>> list of where the node has been since it was first >>>>> installed. >>> I think I can get a list of where a device has been from any >>> number of places. So, I don't buy that argument at all. >> >> >> I buy the argument. Some vendors have been beaten up for it now >> and then. Making that worse while trying to make privacy better >> would be a shame, no? >> >> S. >> >> [1] >> http://www.theguardian.com/technology/2011/apr/20/iphone-tracking-prompts-privacy-fears >> > >> > Duly noted. If that is a concern, then it should be noted in the > draft that storing the address is a bad idea. That way, people > won't be tempted to implement this feature in that way. That'd work for me. Thanks, S. > > Regards, Brian > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJS4QDEAAoJEC88hzaAX42i3R0H/1Q8q35Lv8PIHalZwj2MhX1E LhfoWFcgpouUugWC6Zx0fR4rmeI7E9zT4Y/oXy/Ddb5sZ4Ljm1oqu+9Tf9h5Kumc c0ZffME5zHVJ29M8J0KH39wyzzI8osSUsXBXJUXPwQQl09OV03kdCHuDCbgksvZu c/N1SMRfH5KBKSE4HincvJbDR2mH0liqYKpqHuWRJjKDU61/QxuVMX+LwjXG6t0M 9MQShTbwYRgpfHtHTULBKst2n6reUM0dD0hfskVSfauwOCc56yzgP7UbdYR3LGBX jX7LYVrsLUq/zqKnIelYnBDOA9PK09IipK1sX91DAvi25VGpKxwDQ/ZhQ0iX4e8= =Q83S -----END PGP SIGNATURE----- From fgont@si6networks.com Thu Jan 23 03:50: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 0AD701A042B; Thu, 23 Jan 2014 03:50: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 aF96dBJ7ln-k; Thu, 23 Jan 2014 03:50:42 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 3941D1A03E5; Thu, 23 Jan 2014 03:50:42 -0800 (PST) Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W6InZ-0008GX-FY; Thu, 23 Jan 2014 12:50:17 +0100 Message-ID: <52E10153.8070001@si6networks.com> Date: Thu, 23 Jan 2014 08:47:31 -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 Haberman , Fernando Gont , The IESG Subject: Re: Brian Haberman's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS) References: <20140122202434.30069.4084.idtracker@ietfa.amsl.com> <52E02EAD.1050009@si6networks.com> <52E03BAD.5050306@innovationslab.net> <52E04278.1000401@gont.com.ar> <52E0FF5C.8050906@innovationslab.net> In-Reply-To: <52E0FF5C.8050906@innovationslab.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 11:50:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/23/2014 08:39 AM, Brian Haberman wrote: > > On 1/22/14 5:13 PM, Fernando Gont wrote: >>> All this point is making is that there are a variety of ways >>> of getting this behavior and DNA provided guidance on one way >>> to do that. The simple solution is to refer to those RFCs >>> (informatively) and point out that they describe one way to >>> track which addresses are associated with particular networks. >>> This has the benefit of not forcing re-calculation of the hash >>> on every (re-)connect. >> >> I have no issues with that (I misinterpreted where you were >> going, it seems). >> >> So I guess one could add something along the lines of: "A node >> may use Simple DNA [RFC6059] to reuse a previously-configured >> address for this network without the need to recompute the >> Interface-ID with the scheme specified in this document." >> >> ? >> > > That would work for me. We can wait to see if any of AD has an > issue with this text. My understanding of the discussion with Thomas is that one could rather use the SDNA stuff as a possible source for the Network_ID parameter. That' be great. (I proposed some text to Thomas, and I'm waiting for his response). Regarding use of DNA as proposed in the suggested paragraph above, I have no issues with it, although it seems orthogonal and out of scope *here*. -- i.e., such note might make more sense for the other document that has just been adopted. This one is about what to do when you have already "decided" that you cannot reuse the previously-assigned address. Thoughts? Thanks, - -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJS4QE0AAoJEK4lDVUdTnSS6mwP/jtMdUHmCIUPfQ1jea3VWVta ViGtQJs3zIyODuuK0gq+nzg16HNdBtQnct0K1VXdo3ZZhLVuJsJQUBTCzJKbMFvF +dYwdYDCIRcTjEwLt7+EzQ/my+jhjBsKw0RpFS2xj2pzvk7ZWBChn8SEtxMrU419 aGvpRyh3cFXU7Zmnk6g/eFXm/HUvgUoYxSCbw480XxseuRgA3NyxHchvoLkTt0VF 67Kp3pw75LDU04rCo3zY18l1U2acnv4LzQ4auvpzF4jjuUyQEPvVJde8SB9XVUUn CxZ5bb2YvcHOdWeRB05IrJnBij/Bb1NXHIGtYEnmN4L2pRicVSjeRj/B1gftQ/tl QT1GMaAvak9hB2Qjf78QZn7Atl3Pz1ev1MwfEiODz1GHFoCf4OiBlFsnDWd3gCvG RuMEZ/Jak6RR8zqjwEIVQRiXmmJR+R6LjGsjia1K6r5gxpsWseBsPhRk8QKU9Nze EcbE16pMs645O0H5o3EKoPUzGKTV7d1z9aYjLodCDMS3+LTdF1JlMyVzzgrcZbna DaLU/aPbn+y/IrdfhZrfLl/a8ERCJ6Sv4LMkJzIi8wtSZYEAfJGKDdT9uCJUMyNw FAdmkzmO5BFbSpFjszvTTMM/Y2XxNVF5ysPFurmxOb489DRAJugLh7iBRYARWDuM Uao28y7jpo5VgPCHYHmf =wsjs -----END PGP SIGNATURE----- From brian@innovationslab.net Thu Jan 23 04:01: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 130CE1A042D; Thu, 23 Jan 2014 04:01:43 -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 HWylBZnGqV1M; Thu, 23 Jan 2014 04:01:41 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id C19851A03E6; Thu, 23 Jan 2014 04:01:41 -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 20651880F3; Thu, 23 Jan 2014 04:01:41 -0800 (PST) Received: from clemson.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 31E67130003; Thu, 23 Jan 2014 04:01:40 -0800 (PST) Message-ID: <52E104A4.3040701@innovationslab.net> Date: Thu, 23 Jan 2014 07:01:40 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Fernando Gont , Fernando Gont , The IESG Subject: Re: Brian Haberman's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS) References: <20140122202434.30069.4084.idtracker@ietfa.amsl.com> <52E02EAD.1050009@si6networks.com> <52E03BAD.5050306@innovationslab.net> <52E04278.1000401@gont.com.ar> <52E0FF5C.8050906@innovationslab.net> <52E10153.8070001@si6networks.com> In-Reply-To: <52E10153.8070001@si6networks.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4Q08t0R6o4knKu1SEHIXUMHuShb4kPe08" 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 12:01:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4Q08t0R6o4knKu1SEHIXUMHuShb4kPe08 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/23/14 6:47 AM, Fernando Gont wrote: > On 01/23/2014 08:39 AM, Brian Haberman wrote: >=20 >> On 1/22/14 5:13 PM, Fernando Gont wrote: >>>> All this point is making is that there are a variety of ways >>>> of getting this behavior and DNA provided guidance on one way >>>> to do that. The simple solution is to refer to those RFCs=20 >>>> (informatively) and point out that they describe one way to >>>> track which addresses are associated with particular networks. >>>> This has the benefit of not forcing re-calculation of the hash >>>> on every (re-)connect. >>> >>> I have no issues with that (I misinterpreted where you were >>> going, it seems). >>> >>> So I guess one could add something along the lines of: "A node >>> may use Simple DNA [RFC6059] to reuse a previously-configured=20 >>> address for this network without the need to recompute the=20 >>> Interface-ID with the scheme specified in this document." >>> >>> ? >>> >=20 >> That would work for me. We can wait to see if any of AD has an >> issue with this text. >=20 > My understanding of the discussion with Thomas is that one could > rather use the SDNA stuff as a possible source for the Network_ID > parameter. That' be great. (I proposed some text to Thomas, and I'm > waiting for his response). >=20 > Regarding use of DNA as proposed in the suggested paragraph above, I > have no issues with it, although it seems orthogonal and out of scope > *here*. -- i.e., such note might make more sense for the other > document that has just been adopted. This one is about what to do when > you have already "decided" that you cannot reuse the > previously-assigned address. >=20 > Thoughts? Given the concerns raised by Stephen about storing addresses, I can see where employing the DNA approach for the Network_ID is a reasonable compromise. Regards, Brian --4Q08t0R6o4knKu1SEHIXUMHuShb4kPe08 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 iQEcBAEBCgAGBQJS4QSkAAoJEBOZRqCi7goq3T8H/0rqIimjtewvrvZLFI/4b1S4 lrq04EvjCyosLwAeq1GgHdbi+W2BpuId+n/BFN8bMr4AJ87CKtWw4OWic/PEVeR6 2yuCHd+qn90bnT8Kpjic+UpmSimETmr9gDDregoMgPlfGOaN20sHor6hN72/j88D Db9Olemp6bq5lmXUbzd13CGiaANJgFJd1JQCbyR+0HLYJS0zyygalXPqfXUHByNm TblPZuj+vPTwBMahB8F5+CU4gp5zn3VPGr56U/ChALyen4lm6mhQc60aaE3FFCqx ligTobmBtbkzSAlw5kGX+aF1L9H0E8Ih3GuR9crxnSKB3uEmIPNmNul8QVDLzpM= =C3t+ -----END PGP SIGNATURE----- --4Q08t0R6o4knKu1SEHIXUMHuShb4kPe08-- From fernando@gont.com.ar Thu Jan 23 04:27: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 86B531A03D3; Thu, 23 Jan 2014 04:27:31 -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 WjqVBBNaLjpI; Thu, 23 Jan 2014 04:27:29 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 43C7E1A02C2; Thu, 23 Jan 2014 04:27:29 -0800 (PST) Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W6JMz-0000jO-TA; Thu, 23 Jan 2014 13:26:54 +0100 Message-ID: <52E10557.6030502@gont.com.ar> Date: Thu, 23 Jan 2014 09:04: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: Brian Haberman , Fernando Gont , The IESG Subject: Re: Brian Haberman's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS) References: <20140122202434.30069.4084.idtracker@ietfa.amsl.com> <52E02EAD.1050009@si6networks.com> <52E03BAD.5050306@innovationslab.net> <52E04278.1000401@gont.com.ar> <52E0FF5C.8050906@innovationslab.net> <52E10153.8070001@si6networks.com> <52E104A4.3040701@innovationslab.net> In-Reply-To: <52E104A4.3040701@innovationslab.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 12:27:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/23/2014 09:01 AM, Brian Haberman wrote: >> >> Regarding use of DNA as proposed in the suggested paragraph >> above, I have no issues with it, although it seems orthogonal and >> out of scope *here*. -- i.e., such note might make more sense for >> the other document that has just been adopted. This one is about >> what to do when you have already "decided" that you cannot reuse >> the previously-assigned address. >> >> Thoughts? > > Given the concerns raised by Stephen about storing addresses, I can > see where employing the DNA approach for the Network_ID is a > reasonable compromise. Great. Should I wait for Thomas response, and then rev to address all the comments received so far? (Tim's, Stephen's, yours, Thomas', 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJS4QU7AAoJEJbuqe/Qdv/xffEH/3D6ieGh/WLaGKk8VWn382o7 8T4J62fUVbz1eUsbYQbBIy5IUeO62rD+96ITwbhjgjbCJFmVJfWjRLYM+cdDPz/f EKOFa3sH3zYiIzSWz4SSmOoD3HHss8JO3GQV3l5p2AO0y6GnxM4oGseSrmFN88oT 8k4UvaJ4TLHM2KNiwwVStap4zOA/HttrIzXfzEdrTOjlijcm80ocBOsJlCNvLhwR 7RE8HodFSRzXzmNZKuCD47X5W42sQmzL1U/wYn9M9cppXVG3LFYTtLm3o4WFE9Mf d945X2OC4Sa240o7qWOiOfn1TeEX65uDYZHNXcgKIILf/FTqG1K4f91Jw4RWvGY= =+/qV -----END PGP SIGNATURE----- From brian@innovationslab.net Thu Jan 23 04:34: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 47CDC1A0430; Thu, 23 Jan 2014 04:34:28 -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 cdQEI07gkFKl; Thu, 23 Jan 2014 04:34:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE06E1A03E6; Thu, 23 Jan 2014 04:34:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Brian Haberman" To: The IESG Subject: Brian Haberman's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS) X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140123123426.16950.38439.idtracker@ietfa.amsl.com> Date: Thu, 23 Jan 2014 04:34:26 -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 12:34:28 -0000 Brian Haberman has entered the following ballot position for draft-ietf-6man-stable-privacy-addresses-16: Discuss 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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I am taking the somewhat curious route of raising a DISCUSS on a document that I am shepherding. I will return to a Yes when these issues are resolved. Thomas Narten raised a good point that this document does not mention the work published in RFCs 4436 and 6059 (from the concluded DNA WG). Two of the points he raised are worth addressing in this document prior to publication. 1. [Resolved] - Storing addresses is going to raise privacy issues. 2. DNA provides some ability to manage the Network_ID component of the cryptographic hash. For wired networks, that may be quite useful as long as the Network_ID can be stored securely. From brian@innovationslab.net Thu Jan 23 05:20: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 A273A1A00D4; Thu, 23 Jan 2014 05:20: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 xxNtdtDIj8UX; Thu, 23 Jan 2014 05:20:00 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 123FD1A00CB; Thu, 23 Jan 2014 05:20: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 6C2ED8810A; Thu, 23 Jan 2014 05:19:59 -0800 (PST) Received: from clemson.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 AC288130003; Thu, 23 Jan 2014 05:19:58 -0800 (PST) Message-ID: <52E116F7.8090108@innovationslab.net> Date: Thu, 23 Jan 2014 08:19:51 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Fernando Gont , Fernando Gont , The IESG Subject: Re: Brian Haberman's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS) References: <20140122202434.30069.4084.idtracker@ietfa.amsl.com> <52E02EAD.1050009@si6networks.com> <52E03BAD.5050306@innovationslab.net> <52E04278.1000401@gont.com.ar> <52E0FF5C.8050906@innovationslab.net> <52E10153.8070001@si6networks.com> <52E104A4.3040701@innovationslab.net> <52E10557.6030502@gont.com.ar> In-Reply-To: <52E10557.6030502@gont.com.ar> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wfo0WpnbKKe2G99AgodNhVjgl1FL66lU0" 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 13:20:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wfo0WpnbKKe2G99AgodNhVjgl1FL66lU0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/23/14 7:04 AM, Fernando Gont wrote: > On 01/23/2014 09:01 AM, Brian Haberman wrote: >>> >>> Regarding use of DNA as proposed in the suggested paragraph >>> above, I have no issues with it, although it seems orthogonal and >>> out of scope *here*. -- i.e., such note might make more sense for >>> the other document that has just been adopted. This one is about >>> what to do when you have already "decided" that you cannot reuse >>> the previously-assigned address. >>> >>> Thoughts? >=20 >> Given the concerns raised by Stephen about storing addresses, I can >> see where employing the DNA approach for the Network_ID is a >> reasonable compromise. >=20 > Great. >=20 > Should I wait for Thomas response, and then rev to address all the > comments received so far? (Tim's, Stephen's, yours, Thomas', etc.)? >=20 Yes, let's wait on a revision until we have all the needed updates identified. Regards, Brian --wfo0WpnbKKe2G99AgodNhVjgl1FL66lU0 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 iQEcBAEBCgAGBQJS4Rb9AAoJEBOZRqCi7goq6bcIAIAahORkW5A0F7fsDtWGXDbT cl96BR89vrQhAc/P/4ieeuijbI1sY1a4QDf/aaaK2wrj27ELM7Kz2Zc032Z94zwp D/OpfuA/VnoFeifdJvCk+3mdvra8vUo2Kc/9I6OQhWEPv5ZfAeN/DO2+wbL1HfwZ h0Vt2sZ00SMQKgr96rV3BEnbEvhJ69EfVHVUdpHIuSoyp/QbZ8BJCVqiy8RS91Ie pOs/nGK1hSNb9VDKveHSB735VSqi1Wp2oeTjzixVVCB/xs/z2Ym4rU8VE89hZ1Fu prTeqtNwDr72nCV3owWDIi6cILe/53mfeb3gvu6vKoECW85SIVpw6O7N6wHcF1Q= =vkoH -----END PGP SIGNATURE----- --wfo0WpnbKKe2G99AgodNhVjgl1FL66lU0-- From scott.brim@gmail.com Thu Jan 23 06:36: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 419F41A02DE; Thu, 23 Jan 2014 06:36: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 RaJ6jAB-8PaR; Thu, 23 Jan 2014 06:36:39 -0800 (PST) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B7BF71A00FC; Thu, 23 Jan 2014 06:36:39 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id g12so2211436oah.3 for ; Thu, 23 Jan 2014 06:36:38 -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=9K5suHeCIhLsi8gt4yxmmiTYIuUwY6PvIqWwUD5uImU=; b=whIKRenYIVbqUmF+xmujWSRVgTnk6ouisg16tqOA9UOvDIAiRNDNkgcabncHm7Wc8u Jj4tmsxYU00qVkg4+IGUFHxC9l6ZvlobGPqCox0tiSHMHTiVkXPzEpUJIgh0wOQ4R8kW evpbs3t35G5aDWAga726CqsDccWymBwbsECPSJ2mZzUFv1iz+kb4BxYJDwUd3GHSzkgu 3Y9o0J9+jflFteZQglkAljROcHx6dv++X9jM4NZoOZCJLm8sO5zriWdpJX4tI2MFjWw1 3BSziBvxXhg/rKEbhboiuARl5e21NEWz/CxBE3iVVWb5973PbzBZz+92y/rLguV+IALu 24pQ== X-Received: by 10.182.113.195 with SMTP id ja3mr7037007obb.46.1390487798559; Thu, 23 Jan 2014 06:36:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Thu, 23 Jan 2014 06:36:18 -0800 (PST) In-Reply-To: References: <20140122192018.8692.82071.idtracker@ietfa.amsl.com> From: Scott Brim Date: Thu, 23 Jan 2014 09:36:18 -0500 Message-ID: Subject: Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT) To: Thomas Narten Content-Type: text/plain; charset=ISO-8859-1 Cc: 6man-chairs@tools.ietf.org, Pete Resnick , ipv6 , The IESG , 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 14:36:41 -0000 +1 on Thomas. He said it better than I would have. From lear@cisco.com Thu Jan 23 07:09: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 A1B1B1A0016; Thu, 23 Jan 2014 07:09:32 -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 DAtSlewXZvLg; Thu, 23 Jan 2014 07:09:31 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id D264E1A000E; Thu, 23 Jan 2014 07:09:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=836; q=dns/txt; s=iport; t=1390489770; x=1391699370; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=EV5uxxB4fHw81ULP72ugSzQb32yDjhSb20WxbK/4ftc=; b=eQC9GwNz0sGgmDRmTIgHoazNFdNseoDWA14Y6CQtCAXzTUmZ+HH5S9y3 VOwSc+lI05b+gIRqxD1ApBnLQliL4r/OjZkZSQH0LKqx1LYYB/XTQEMp6 JQfv20J74p39662YtTX8jIgMococ834L06viPOeSN435ihsUkdMrQRCpS c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAEcw4VKQ/khL/2dsb2JhbABbgwyEDLh1gRAWdIIlAQEBBCNVARALDgoCAgUWBAcCAgkDAgECAUUGAQwBBwEBiAGpVJwXF4EpjVcHgm+BSQEDmCOSGIFvgT87 X-IronPort-AV: E=Sophos;i="4.95,706,1384300800"; d="scan'208";a="4076513" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 23 Jan 2014 15:09:28 +0000 Received: from dhcp-wlsn01-vlan250-10-147-28-17.cisco.com (dhcp-wlsn01-vlan250-10-147-28-17.cisco.com [10.147.28.17]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0NF9Rgd023908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Jan 2014 15:09:27 GMT Message-ID: <52E130A7.5050102@cisco.com> Date: Thu, 23 Jan 2014 16:09:27 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Fernando Gont , Stephen Farrell , Simon Perreault , 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> <52DEB873.1080500@cs.tcd.ie> <52DEC5C8.7080903@si6networks.com> In-Reply-To: <52DEC5C8.7080903@si6networks.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 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: Thu, 23 Jan 2014 15:09:32 -0000 Fernando, 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. But maybe I misunderstood. Eliot From presnick@qti.qualcomm.com Thu Jan 23 08:56: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 044D01A0041; Thu, 23 Jan 2014 08:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.836 X-Spam-Level: X-Spam-Status: No, score=-4.836 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_MED=-2.3, 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 p_QmA6YUPXwi; Thu, 23 Jan 2014 08:56:31 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 931FF1A0028; Thu, 23 Jan 2014 08:56:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1390496192; x=1422032192; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=J2++WgbBM/dRSUYMb4hQ5Bk6iTCx6l2p8wErL7ttJgY=; b=qjo/Hm9KbLQOJyvDQgWpTzMNLbOkdpXn0aIO3+QA4x/1Zg6Pyn/uiCaE 05rLqS8XWOG/zgeeHcISaZekqVTbmniEdVwtktnfs2ylyi/DQuM1AMRLn gnw0b7TAEEQ31i82RZo3mkndO8xWL/FWtKj+lAJkrQ+ZqMdshc4kTxN9U U=; X-IronPort-AV: E=McAfee;i="5400,1158,7326"; a="10020121" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 23 Jan 2014 08:56:31 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,7326"; a="672379856" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 23 Jan 2014 08:56:30 -0800 Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Jan 2014 08:56:30 -0800 Message-ID: <52E149BC.3090007@qti.qualcomm.com> Date: Thu, 23 Jan 2014 10:56:28 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Thomas Narten Subject: Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT) References: <20140122192018.8692.82071.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, The IESG , 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 16:56:34 -0000 On 1/22/14 8:07 PM, Thomas Narten wrote: > Glad this is only a comment, but I think if one argues this document > shouldn't be PS, it opens up the door to saying a rather substantial > number of the standards the IETF has produced in the past should not > be on standards track either. > > I think its worth noting that the classifications we have > (standard/info/bcp/applicability statements) have a very course > granularity. There are lots of individual "things" that don't fit > cleanly into exactly one category, if you start looking closely. > We're now off into "the bigger picture", but I do think we've been pretty lousy about deciding once and for all what we mean by certain documents. Coarse-grained is fine, and I don't have a problem with us picking "the best fit" when a document isn't clearly one or the other. The problem is that we are now in a state of assigning states for marketing reasons ("people will take this more seriously if we make it a standard") rather than to improve how we do things on the Internet. I think it weakens the document series generally to be calling things standards that aren't and vice-versa. With documents that should be Informational that are called standards, people start turning into the protocol police ("The document says you MUST have a button to switch this feature off, and you don't expose that in the UI; you are required by the IETF to fix your UI") and people start viewing the things that *are* interoperability standards as conformance documents. It lowers the usefulness and relevance of our protocols. The problem is not where any given document goes. It's that we haven't been good about defining the categories clearly. > For example, the IETF doesn't really (usually) produce informational > documents that people go off and implement. If you are going to code > something, then presumably you want all implementations do things in a > certain way (so they exhibit important behavior). And you want to be > able to verify that implementations were able to implement from the > spec (perhaps using MUST/SHOULD type language - or perhaps not). We > get that with standards track documents. We have no mechanism in our > processes for reviewing Informational RFCs and whether they were > implementable and meet our criteria for being called a standard. Isn't > that one of the core reasons the IETF exists? > To a certain extent. It is true that one of the aspects of standardization is implementability. But we are supposed to judge implementability from a standpoint of interoperability. In fact, we are quite clear that it is *independent* implementation is key: We *don't* want people implementing things exactly the same way, because that makes for brittle implementations. What we want is for the network-visible output of those implementations to do certain things, but we want the implementations to be independent and we ignore their local (i.e., non-networked) behaviors. So while I agree that we usually don't produce informational document that people go off and implement, I would add that we usually don't (and generally shouldn't) produce standards track documents that prescribe specific local implementation details that do not affect interoperability. In those instances we think that a local implementation problem is important to explain ("Every implementation ends up needing to do X, and we've seen that they never seem to get it right, so here's a a way to do it"), even though we are not saying it is necessary for interoperability, I think an Informational document is appropriate if it's going to be a separate document. (Sometimes a BCP is also reasonable, if we find that we need to give policy or operational guidance to deployment.) > Thus, for IETF WGs, I would say that the vast majority of stuff that > is produced that describes an implementation should be on standards > track. > I agree with the general statement. The issue is that there are a bunch of things about local implementation details that I don't think we should be making normative statements about at all. When we do want to make statements about local implementation details, I don't think those statements should be on the standards track. > This document fits squarely in that category. > > >> This is an algorithm to generate stable, private, and mostly unique >> addresses. It does not affect interoperability at all if people choose >> a different method. >> > Sure it may. How will it? > If we want the IETF "standard" to be "generate addresses > however you want, hopefully they will work, but it's not the business > of an IETF standard to tell you how to ensure you are doing things > right", then I guess publishing this document as informational (and > giving it the same status as an RFC such as "FooBar's Proprietary > Protocol") would be the way to go. > I am curious about the "doing things right" bit. If doing things right is simply "it must be stable, private, and unique", and we're giving an example about how to get such a thing, peachy. But this document does more than that. It says, for example, that the DAD_Counter MUST start at zero and go up. But of course my implementation doesn't need to do that. I could plausibly start high and work my way down (if I were being recalcitrant). I could also come up with something nifty other than the Prefix to put into my generator. And if either of these things works better in my implementation (because it's more efficient, or I'm in a weird local environment that makes doing it the way the document describes hard) and I'm still able to produce stable, private, and unique addresses, that's fine and the IETF can take their standard and piss-off. > But be careful what you wish for. I'm pretty sure the IPv6 addressing > architecture shouldn't be on standards track per your argument. And > maybe the original SLAAC spec shouldn't be either. Beware the slippery > slope. > Well, if this document was saying, "You MUST have addresses that are private because doing otherwise exposes information and potentially harms things" and therefore updated the old way of doing address selection, I would be more inclined to say that this is a reasonable as a standard because it's saying that this is the one way we've all agreed to accomplish this and other ways are bad. But from what I understand, the WG is not inclined to do that. >> Anyone can accomplish the same task in a number of >> different ways. This is just a nice method to use if someone wanted to >> use it. This should just be an Informational document explaining a >> nice way to generate stable, private, mostly unique addresses without >> all of the MUSTs and SHOULDs, which are not interoperability >> requirements in the first place. Standardizing this is silly in the >> extreme. >> > Others have commented on this, but it is perfectly fine (and has been > in the IETF for a long time) to use MUST/MAY type language in > informational documents. Especially ones that describe protocol > details. Why bring up this Red Herring? > It's not the existence of the MUSTs and SHOULDs, it's what they are requiring in this document. They are not requiring things that are required for interoperation or to prevent harm. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From rdroms.ietf@gmail.com Thu Jan 23 09:48: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 D78621A0131 for ; Thu, 23 Jan 2014 09:48: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 uej11AXfvl6K for ; Thu, 23 Jan 2014 09:48:13 -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 00A301A004C for ; Thu, 23 Jan 2014 09:48:12 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id rq2so2116846pbb.17 for ; Thu, 23 Jan 2014 09:48:12 -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=GpJE3CDiab8cagA5ylVZgAQK70et9NgpeI/RZLlbeg8=; b=0PB88rOt2CJcCYv6bFq/DBG4QapGOwsP/KycjhE2qhiMHNqUACxYniURHToQcnH4cq 1z/kFlrQ+rcCU6LBzjP/bTvtTikiJcgdlAYaTRoEk/AFEZgHQS19x9P/EdV7RVEkGXLx mojM/TPz0McMxI6Xj8CsqeJqs4+mEKzShxwMzS8oYYDUFOGIlXKij91s4s2917knxwfk pAcEOGbeoVwyFRD/odOMQfp1tYvIdyEsqaq8dBN3LlBpQTwRXomzClmT8WlRs918X150 ZBdtydQR8YrCWQ6d3Fe/gIZibzO+cXjZdH+hiD9JKZcGamnbztkN9BJ+EADeIlt4wWa8 1pcg== X-Received: by 10.68.114.99 with SMTP id jf3mr9260177pbb.67.1390499292179; Thu, 23 Jan 2014 09:48:12 -0800 (PST) Received: from sjc-vpn7-223.cisco.com (128-107-239-234.cisco.com. [128.107.239.234]) by mx.google.com with ESMTPSA id xv2sm39279076pbb.39.2014.01.23.09.48.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Jan 2014 09:48:11 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt From: Ralph Droms In-Reply-To: Date: Thu, 23 Jan 2014 09:48:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131021233827.32495.34424.idtracker@ietfa.amsl.com> To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.1510) Cc: draft-ietf-6man-resilient-rs@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 17:48:15 -0000 On Jan 22, 2014, at 11:46 AM 1/22/14, Lorenzo Colitti = wrote: > [...] >=20 > This may be difficult to specify correctly. Specifically, it may be = hard to distinguish something that is being deprecated by the network = (e.g., an RA whose lifetime is counting down because it comes from a PD) = from an RA that is about to expire. Might not be necessary to differentiate. Regardless of why the prefix = lifetime expired and whether the host has configured other , the host = will likely want to send periodic RSs in case a new prefix becomes = available and "unsolicited multicast Router Advertisements are never = sent" implies no RA to announce new prefixes. - Ralph >=20 > If the intent is not that we should be able to run networks without = periodic RAs, then at least the text in 2b needs to change. >=20 > Cheers, > Lorenzo > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From fgont@si6networks.com Thu Jan 23 09:49: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 ABB361A007D; Thu, 23 Jan 2014 09:49:43 -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 uQs_Qsc8xtXj; Thu, 23 Jan 2014 09:49: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 440B91A0019; Thu, 23 Jan 2014 09:49:38 -0800 (PST) Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W6OOd-0000JU-0b; Thu, 23 Jan 2014 18:48:55 +0100 Message-ID: <52E14FBB.1070901@si6networks.com> Date: Thu, 23 Jan 2014 14:22: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: Eliot Lear , Stephen Farrell , Simon Perreault , 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> <52DEB873.1080500@cs.tcd.ie> <52DEC5C8.7080903@si6networks.com> <52E130A7.5050102@cisco.com> In-Reply-To: <52E130A7.5050102@cisco.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 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: Thu, 23 Jan 2014 17:49:43 -0000 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 ietf-secretariat-reply@ietf.org Thu Jan 23 09:58: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 3EB3E1A018C for ; Thu, 23 Jan 2014 09:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 s-JUsv_I5FRg; Thu, 23 Jan 2014 09:58:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 742101A0185; Thu, 23 Jan 2014 09:58:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: 6man-chairs@tools.ietf.org, draft-ietf-6man-stable-privacy-addresses@tools.ietf.org, ipv6@ietf.org Subject: ID Tracker State Update Notice: X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140123175809.15224.28737.idtracker@ietfa.amsl.com> Date: Thu, 23 Jan 2014 09:58:09 -0800 From: IETF Secretariat 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 17:58:18 -0000 State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-6man-stable-priv= acy-addresses/ From lorenzo@google.com Thu Jan 23 10:52: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 82C371A0035 for ; Thu, 23 Jan 2014 10:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 U6nJn8hXbDYi for ; Thu, 23 Jan 2014 10:52: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 036901A0024 for ; Thu, 23 Jan 2014 10:52:54 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id u16so1662981iet.29 for ; Thu, 23 Jan 2014 10:52:54 -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=Rvu+rAcz/W1DlOPTyzLNNgfPgzJF5476Xhw0wyVnWU0=; b=aOcNog0957CCfWMnKPhv3EDiDhV/Wrh3X+c94Ux6+SM99O1XoIkM/Hj4BHN+j2qAj+ BkE/2hG6xFomQ4C+qX5WhkqaxdIZ6vGWMAh7ZTyzCr/AXKN7AH+F9HFXmF/1NbwWclaE QuyUFv/ytGpprSFwRJq6Paz3WfR97QeTajSdbnj21wh/w3X0ol0q0He7L3hWnNAoCEbK HTgHnBFum2rIRKDSWBo0tVFSteyxlwqatPG0etEurVBGAcnNr6/dAjqkMnnGMW/gRetI qqSGEd8tzIy0WzMtUzSaaJB2eNWoZv+y+rBwGEuiH8mOWxiPHfZKkJsntM8u/9+FPIyc 1/WQ== 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=Rvu+rAcz/W1DlOPTyzLNNgfPgzJF5476Xhw0wyVnWU0=; b=aMv3GdbhSZnHY3zaxjJ96sx9XVRZqgdChON4Vidf5WLnMR1pZTq+DPPXEn1HU2Dofp KvRZ0XH9r85HtNspytsuu2m2MbG9Hf0zPybElE3LMzIMqFeN4UgMf3eYF4Kr3cowbWnj QO6sZq+NRECcTcLrnt8wUMB66d8lO2PZXxuJ2Qhfc0J5MSEqeouaGcfC5todi9K2eaKx V2AThl/fDxoUJhYc4aKMhJXx9U+IJOE2ZBH7STfMJtU0DItLkwYmxpuyufcRS/5l+gTX rEC294TIR/fUoOLBTnWgF3NyT0PlNCU+tKmk4cSiTZNKGSeyUgMzoPS7LfNJK5h2yBOz jKaw== X-Gm-Message-State: ALoCoQlJa2ve7g22Xhsv/rASIstdmn5ktrMq0T+nWWT3AIiJ0Q2nz4STNR5374dhWy0HaelxcxgAFDRR8BucgUiTRgU4htLFT90t7bq02UiHhROIoryXjEnYdg4PWaq5ENXGMKpSLqAl33huG3Bwej/bnU2aIjKxeYwtxMt0Z1/+R7uBineSv62LLFuyieYqr/mmmdNqcP2t X-Received: by 10.42.197.134 with SMTP id ek6mr543176icb.97.1390503173772; Thu, 23 Jan 2014 10:52:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Thu, 23 Jan 2014 10:52:33 -0800 (PST) In-Reply-To: References: <20131021233827.32495.34424.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Thu, 23 Jan 2014 10:52:33 -0800 Message-ID: Subject: Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt To: Ralph Droms Content-Type: multipart/alternative; boundary=20cf303ea61abbc39104f0a7bff3 Cc: IETF IPv6 Mailing List , draft-ietf-6man-resilient-rs 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 18:52:58 -0000 --20cf303ea61abbc39104f0a7bff3 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 23, 2014 at 9:48 AM, Ralph Droms wrote: > > This may be difficult to specify correctly. Specifically, it may be hard > to distinguish something that is being deprecated by the network (e.g., an > RA whose lifetime is counting down because it comes from a PD) from an RA > that is about to expire. > > Might not be necessary to differentiate. Regardless of why the prefix > lifetime expired and whether the host has configured other , the host will > likely want to send periodic RSs in case a new prefix becomes available and > "unsolicited multicast Router Advertisements are never sent" implies no RA > to announce new prefixes. > That's true, but then you get into Erik's concern that whenever a host sees that $SOMETHING is about to expire then it sends out an RS with exponential backoff (until what? until it gets an RA - any RA, from anyone?). The concern is that basically ends up with hosts sending RSes all the time - in other words, you implement dynamic reconfiguration via polling. This is not necessarily a good use of hosts' CPU and battery resources. I do think that nodes should be free to send RSes if they so choose, and I think we should say that a host MAY do so in this draft, but I don't think we should attempt to design an architecture that depends on polling. Any objection to saying that hosts MAY send RSes when they want to refresh information (e.g., when it's about to expire)? --20cf303ea61abbc39104f0a7bff3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 23, 2014 at 9:48 AM, Ralph Droms <rdroms.ietf@gmail.com>= ; wrote:
> This may be difficult to specify c= orrectly. Specifically, it may be hard to distinguish something that is bei= ng deprecated by the network (e.g., an RA whose lifetime is counting down b= ecause it comes from a PD) from an RA that is about to expire.

Might not be necessary to differentiate. =C2=A0Regardless of why the = prefix lifetime expired and whether the host has configured other , the hos= t will likely want to send periodic RSs in case a new prefix becomes availa= ble and "unsolicited multicast Router Advertisements are never sent&qu= ot; implies no RA to announce new prefixes.

That's true, but then you get into Eri= k's concern that whenever a host sees that $SOMETHING is about to expir= e then it sends out an RS with exponential backoff (until what? until it ge= ts an RA - any RA, from anyone?).

The concern is that basically ends up with hosts sendin= g RSes all the time - in other words, you implement dynamic reconfiguration= via polling. This is not necessarily a good use of hosts' CPU and batt= ery resources.

I do think that nodes should be free to send RSes if th= ey so choose, and I think we should say that a host MAY do so in this draft= , but I don't think we should attempt to design an architecture that de= pends on polling.

Any objection to saying that hosts MAY send RSes when t= hey want to refresh information (e.g., when it's about to expire)?
--20cf303ea61abbc39104f0a7bff3-- From fgont@si6networks.com Thu Jan 23 14:06: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 4687F1A0154; Thu, 23 Jan 2014 14:06:41 -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 TDs312abNqP8; Thu, 23 Jan 2014 14:06:39 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 085ED1A00AA; Thu, 23 Jan 2014 14:06:38 -0800 (PST) Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W6SPq-0006kH-SI; Thu, 23 Jan 2014 23:06:27 +0100 Message-ID: <52E191CE.80408@si6networks.com> Date: Thu, 23 Jan 2014 19:03:58 -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: l.wood@surrey.ac.uk, lear@cisco.com, stephen.farrell@cs.tcd.ie, simon.perreault@viagenie.ca, iesg@ietf.org 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> <52DEB873.1080500@cs.tcd.ie> <52DEC5C8.7080903@si6networks.com> <52E130A7.5050102@cisco.com>, <52E14FBB.1070901@si6networks.com> <290E20B455C66743BE178C5C84F1240847E63346E4@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E63346E4@EXMB01CMS.surrey.ac.uk> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 22:06:41 -0000 On 01/23/2014 06:58 PM, l.wood@surrey.ac.uk wrote: > is the secret key sent over th e network? at that point, it would stop being secret. Nope. Randomly selected and stored on the node upong systems installation. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From gdaley@au.logicalis.com Thu Jan 23 14:56: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 185B31A0182 for ; Thu, 23 Jan 2014 14:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.442 X-Spam-Level: X-Spam-Status: No, score=-1.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.535, 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 PpIXYdf14mC5 for ; Thu, 23 Jan 2014 14:56:54 -0800 (PST) Received: from smtp1.au.logicalis.com (smtp1.au.logicalis.com [203.8.7.132]) by ietfa.amsl.com (Postfix) with ESMTP id B2D4B1A00B6 for ; Thu, 23 Jan 2014 14:56:53 -0800 (PST) Received-SPF: None (smtp1.au.logicalis.com: no sender authenticity information available from domain of gdaley@au.logicalis.com) identity=mailfrom; client-ip=203.8.7.161; receiver=smtp1.au.logicalis.com; envelope-from="gdaley@au.logicalis.com"; x-sender="gdaley@au.logicalis.com"; x-conformance=spf_only Received-SPF: None (smtp1.au.logicalis.com: no sender authenticity information available from domain of postmaster@sdcexchht.au.logicalis.com) identity=helo; client-ip=203.8.7.161; receiver=smtp1.au.logicalis.com; envelope-from="gdaley@au.logicalis.com"; x-sender="postmaster@sdcexchht.au.logicalis.com"; x-conformance=spf_only Received: from unknown (HELO sdcexchht.au.logicalis.com) ([203.8.7.161]) by smtp1.au.logicalis.com with ESMTP; 24 Jan 2014 10:03:05 +1100 Received: from SDCEXCHMS.au.logicalis.com ([10.18.196.50]) by sdcexchht.au.logicalis.com ([fe80::68b7:8880:fefb:f742%12]) with mapi id 14.02.0347.000; Fri, 24 Jan 2014 09:56:51 +1100 From: Greg Daley To: 'Mark ZZZ Smith' , 'Ing-Wher Chen' , "ipv6@ietf.org" Subject: RE: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt Thread-Topic: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt Thread-Index: AQHPDmY2hGYF66RRbk+N6Vv6p523J5qDMmwwgAATMeCABOYbYIABVfwAgAMsKbCAAxYXAIABtI4w Date: Thu, 23 Jan 2014 22:56:50 +0000 Message-ID: <72381AF1F18BAE4F890A0813768D992817FD2F13@sdcexchms.au.logicalis.com> References: <20140111004402.10451.90724.idtracker@ietfa.amsl.com> <72381AF1F18BAE4F890A0813768D992817FCA84E@sdcexchms.au.logicalis.com> <1390035508.23310.YahooMailNeo@web120503.mail.ne1.yahoo.com> <72381AF1F18BAE4F890A0813768D992817FCDDEC@sdcexchms.au.logicalis.com> <1390379588.46492.YahooMailNeo@web120506.mail.ne1.yahoo.com> In-Reply-To: <1390379588.46492.YahooMailNeo@web120506.mail.ne1.yahoo.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.196.183] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.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 22:56:56 -0000 Hi Mark,=20 I guess it is for others to identify if the protection is sufficient, I wou= ld just like to show that there is a feasible mitigation with MLD. [chop] >> Unless the router maintains additional ND cache state, it cannot=20 >> distinguish between an activated group and which of the addresses is=20 >> active, and thus a subset of the addresses (e.g. the globally routable=20 >> equivalent of a Link-local address with a particular solicited nodes=20 >> [and anything with the same IID lower order bits]). >>=A0 > True. The presence of a solicited-node group on a link only indicates at = least one of the addresses that would map to it is present. >> Is this sufficient protection, or does there have to be more specific=20 >> state gathered in the ND cache, perhaps through the discussed draft? >>=A0 > I see this idea as another quite useful mitigation, but certainly not a p= revention of the ND cache DoS attack. > As the number of present solicited-node groups is very unlikely to ever e= xceed 1% of the total available solicited-node groups (2^24/16M), that mean= s > that NSes don't have to be performed for destination addresses that map t= he the remaining 99% of solicited-node groups. This is in comparison to > today where NSes would be performed for any unknown destination within th= e /64. I think that would be another measure that usefully reduces the > effectiveness of the off-link ND cache DoS attack against a router. Less = predictable solicited-node groups, as a result of > draft-ietf-6man-stable-privacy-addresses, would further reduce the effect= iveness of the off-link ND cache DoS. > I though of this idea while thinking about how MLD/solicited-node group m= embership might be able used to facilitate node registration, preventing > the router ND cache DoS attack. It previously occurred to me that if node= s are using MLDv2, meaning that all nodes report their membership of all > groups, then routers tracking solicited-node membership would now have kn= owledge of one of all of the attached nodes' link-local addresses (either a= s > the nodes initialise their addresses, or because a router initiates a que= rier election when it initialises) . If the nodes then supported Inverse ND= +, > then the routers could query the nodes for their other addresses, giving = them complete knowledge of all unicast addresses on all nodes, achieving > complete node registration. NUD would then take care of expiring node reg= istrations when the nodes disappear.=A0 I think that the value principally comes from the mandatory nature of MLD (= though in MLDv1, a node can fail to transmit a report IFF there is another = member of the group that has visibly reported - which activates the group a= nyway). Additional information is probably extraneous and is limited by the fact th= at devices may not have implemented particular capabilities (i.e. they are = not required by the Node Requirements RFC6434) Greg Daley From internet-drafts@ietf.org Fri Jan 24 06:21: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 0BB941A04AF; Fri, 24 Jan 2014 06:21:43 -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 UVAGnbfXLBsC; Fri, 24 Jan 2014 06:21:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A70991A04A6; Fri, 24 Jan 2014 06:21:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-default-iids-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140124142141.1829.4747.idtracker@ietfa.amsl.com> Date: Fri, 24 Jan 2014 06:21:41 -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: Fri, 24 Jan 2014 14:21:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Recommendation on Stable IPv6 Interface Identifie= rs Authors : Fernando Gont Alissa Cooper Dave Thaler Will Liu Filename : draft-ietf-6man-default-iids-00.txt Pages : 10 Date : 2014-01-24 Abstract: Stateless Address Autoconfiguration (SLAAC) for IPv6 typically results in hosts configuring one or more stable addresses composed of a network prefix advertised by a local router, and an Interface Identifier that typically embeds a hardware address (e.g., an IEEE LAN MAC address). The security and privacy implications of embedding hardware addresses in the Interface Identifier have been known and understood for some time now, and some popular IPv6 implementations have already deviated from such schemes to mitigate these issues. This document recommends [I-D.ietf-6man-stable-privacy-addresses] as the default scheme for the generating stable IPv6 addresses and recommends against embedding hardware addresses in IPv6 Interface Identifiers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-default-iids/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-default-iids-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tjc@ecs.soton.ac.uk Fri Jan 24 08:53: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 66F041A0016; Fri, 24 Jan 2014 08:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.756 X-Spam-Level: X-Spam-Status: No, score=-1.756 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_NEUTRAL=0.779] 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 GN9yLNnN8sJI; Fri, 24 Jan 2014 08:53:07 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 898411A0057; Fri, 24 Jan 2014 08:53:02 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s0OGqh8h000522; Fri, 24 Jan 2014 16:52:43 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s0OGqh8h000522 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1390582363; bh=rnqaIK520lT0N7aZK5EWTO532oE=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=s3HgL/Z2l0KMLppjWhd4JwNXnVw5fQvBQGVMfxsEquum9QawXV6S/hJLWY7HPkrWE j3tESBEP/Lb/9JYKELct/A1xi1/b1bz1BW8+7NN8pz7ghJXq55SShSLAs7pTppPVYd 9UkfQuTJ7WGM+6Mm+E/KQuGoqRcrbOboBilR2wxI= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id q0NGqh0959621873Vn ret-id none; Fri, 24 Jan 2014 16:52:43 +0000 Received: from dhcp-161-173.wireless.soton.ac.uk (dhcp-161-173.wireless.soton.ac.uk [152.78.161.173] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s0OGqeWD016001 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 Jan 2014 16:52:41 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Benoit Claise's No Objection on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT) From: Tim Chown In-Reply-To: <52E1009F.2040104@innovationslab.net> Date: Fri, 24 Jan 2014 16:52:43 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140123092102.22697.55292.idtracker@ietfa.amsl.com> <52E1009F.2040104@innovationslab.net> <325221D1-3669-4F2E-A264-FA5F8FBA9BC5@ecs.soton.ac.uk> To: Brian Haberman X-Mailer: Apple Mail (2.1510) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q0NGqh095962187300; tid=q0NGqh0959621873Vn; client=relay,ipv6; mail=; rcpt=; nrcpt=6:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s0OGqh8h000522 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: Benoit Claise , 6man-chairs@tools.ietf.org, ipv6@ietf.org, The IESG , 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: Fri, 24 Jan 2014 16:53:09 -0000 Hi, On 23 Jan 2014, at 11:44, Brian Haberman = wrote: > Tim & Benoit, >=20 > On 1/23/14 4:21 AM, Benoit Claise wrote: >> Benoit Claise has entered the following ballot position for >> draft-ietf-6man-stable-privacy-addresses-16: No Objection >>=20 >> 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.) >>=20 >>=20 >> Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> = http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Please Tim's OPS DIR review (currently under discussion) >>=20 >> First, I would note that I have already contributed comments/text to = this >> draft, as acknowledged by Fernando. It=92s been a few versions since = I >> last read it. >>=20 >> The goal of the draft has considerable merit, and I believe the = document >> is worthy of publication, subject to comments belwo being considered. >>=20 >> I would classify the document as =91Ready with issues=92. >>=20 >> Issues: >>=20 >> 1. In the discussion in section 5 on the algorithm, it may be = desirable >> to suggest that implementations allow a choice of IID generation = based on >> =91classic=92 SLAAC with EUI-64 or via this new proposed method, with = a >> default of the new method. >>=20 >=20 > Actually, this preference is out of scope for this document. There is = a > BCP in the works within 6MAN that will describe the current thinking = on > which IID-generation mechanisms should be preferred. OK, that makes sense. I agree that such a document on IID-generation = would be very useful if the topic is not mentioned in this draft. It may be an excuse to dust off = draft-chown-6man-tokenised-ipv6-identifiers as one option... Tim >=20 > Regards, > Brian >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From tjc@ecs.soton.ac.uk Fri Jan 24 09:14: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 5A7971A04C9; Fri, 24 Jan 2014 09:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.755 X-Spam-Level: X-Spam-Status: No, score=-1.755 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.535, SPF_NEUTRAL=0.779] 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 nTTuJd7F0q5A; Fri, 24 Jan 2014 09:14:11 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 343381A04C8; Fri, 24 Jan 2014 09:14:11 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s0OHE7Lb007411; Fri, 24 Jan 2014 17:14:07 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s0OHE7Lb007411 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1390583648; bh=+5MbO6U2h6wkBosRilruTUzX7gc=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=Gcyu90Zj+q5Ixs86GaFdtLllaZTPIrpqA2YaGKdibB4iNaESMU+g8z+fMNQir6udc NK8KtPwYIZOj4Bu9Ph22lr0KtA3krGKI4dGHVtmq1hj5bW7EwYVEn2igq6kMzb5MmB gBC5xmPrZa162FBXAoFqMe4T9sgLCrsZ9FKnzKMc= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q0NHE70959622107gg ret-id none; Fri, 24 Jan 2014 17:14:07 +0000 Received: from dhcp-161-173.wireless.soton.ac.uk (dhcp-161-173.wireless.soton.ac.uk [152.78.161.173] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s0OHE3nn021905 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 Jan 2014 17:14:03 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_046325FD-7709-49FD-88CC-C3F62EC42B7C" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: OPS-DIR review of draft-6man-stable-privacy-addresses-16 From: Tim Chown In-Reply-To: <52E0C6A8.3050503@si6networks.com> Date: Fri, 24 Jan 2014 17:13:28 +0000 Message-ID: References: <52E0C6A8.3050503@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1510) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q0NHE7095962210700; tid=q0NHE70959622107gg; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s0OHE7Lb007411 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: 6man-chairs@tools.ietf.org, ops-dir@ietf.org, ipv6@ietf.org, draft-ietf-6man-stable-privacy-addresses.all@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, 24 Jan 2014 17:14:17 -0000 --Apple-Mail=_046325FD-7709-49FD-88CC-C3F62EC42B7C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, On 23 Jan 2014, at 07:37, Fernando Gont wrote: > Hi, Tim, >=20 > Thanks so much for your feedback! Please find my comments in-line... >=20 > On 01/22/2014 10:05 PM, Tim Chown wrote: >> Issues: >>=20 >> 1. In the discussion in section 5 on the algorithm, it may be >> desirable to suggest that implementations allow a choice of IID >> generation based on =91classic=92 SLAAC with EUI-64 or via this new >> proposed method, with a default of the new method. >=20 > This point is actually addressed by the draft-ietf version for > deprecate-eui64 (which will not deprecate eui64, but will specify the > default). >=20 > i.e., this document just focuses on how you implement stable-privacy. > The draft-ietf version of deprecate-eui64 > (draft-ietf-6man-ipv6-defult-iids) seems like the place to specify = that > of having a knob to configure which method to use... I think Brian has cleared this point up (issue to be described in a = separate text). >=20 >=20 >> 2. In the algorithm section, there is a comment that interface names >> MUST remain the same across boots or down/up events for the stable >> privacy address to remain stable.=20 >=20 > Strictly speaking, it says that Net_Iface MUST be constant. Then > Appendix A discusses possible sources for NetIface... >=20 >=20 >> I have (admittedly some time ago, >> and in rare cases) seen Linux installations where network interface >> names can =91swap=92, thus changing the address in use on the = interface >> under the proposed algorithm, whereas with existing EUI64 SLAAC the >> IIDs would remain the same even if the interface name for a physical >> interface changed. This is probably rather more likely if replacing a >> network card on motherboard with on-board NIC(s). Perhaps Fernando >> can comment on whether this is a realistic concern with modern OSes. >=20 > I think I was told that this has been fixed in Linux . That said, we > don't require any specific source for NetIface. For instance, you can > even use the link-layer address (please see Section A.3), such that = you > get the same stability properties as EUI64 SLAAC. > The rationale for not requiring any specific source is that an > implementer know better which source is more stable/convenient. Some > source might be stable in one OS, but not in others. And viceversa. It does seem that each of those sources listed in the Appendix may not = be constant. That may of course depend on hardware as well as OS. I guess there can be no 100% guarantee for all platforms, so the = document should note that, and the implications. For example, the last = para in Section 1 could instead say: "This document specifies a method to generate Interface Identifiers = that, subject to a constant/stable interface identifier being available, = are stable/constant for each network interface within each prefix", or = something like that. It should be noted that if no such table identifier is available, a = stable IID per prefix can't be guaranteed (unless stable storage for = visited prefixes is used, which has significant privacy concerns as = discussed earlier this week...) >> 3. I assume the IID may/will vary for a different OS run on the same >> host, e.g. where the host is dual-boot, or where a new OS installed >> (or the same OS re-installed). A different OS may well use a >> different F(), given that=92s not specified. With EUI-64, a = dual-boot >> host would likely have the same address under either OS (well, not >> Windows any more=85). This may be worth making explicit. >=20 > This could be a pro or con, one might say. >=20 > I guess we could add something along the lines of: >=20 > "Since different implementation are likely to use different values for > secret_key, and may also employ different PRNGs for F() and different > surces for NetIface, we note that an a host that is dual-boot or that = is > reinstalled may result in different IPv6 addresses for each OS and/or > installation."? That could work. Or you could maybe have a section or subsection that = documents cases where a stable IID can't be guaranteed. The case above = is one, and dual-boot or a reinstalled OS is another? Are there other = cases? >> 4. The draft talks (in one place in Section 3) about stable privacy >> addresses being allocated by DHCPv6; some further discussion of how >> this might be achieved may be useful given the secret key is presumed >> to be generated on and reside on the host, not the DHCPv6 server. Or >> would this be described in a separate future draft?=20 >=20 > Yes, a future draft -- e.g. where the algorithm is computed by the > DHCPv6 server. So one thing to consider here is that unless the 'secret_key' is = shared/copied between the host and the DHCPv6 server, a subnet which = changes to/from DHCPv6 to/from RAs for address configuration will see = the IID change. Maybe this is a third case of the above... >=20 >> 5. Design goal 1 might add =93and same interface=94 for scenarios = where a >> host has two interfaces in the same subnet (with the same prefix). >> This scenario is one that may cause =91interesting=92 effects with >> addresses if interface names swap and no Network_ID is used. >=20 > Will do. (the seconds sentence already notes this). >=20 >=20 >=20 >> 6. I=92d suggest not mentioning MD5. >=20 > Yep. Will do. >=20 >=20 >=20 >=20 >> Nits: >>=20 >> 1. Some references are included multiple times, e.g. [RFC4941], >> rather than only at the first instance. >=20 > I will check this -- it could be that I'm referring to different terms > of the same specs.... or just me being plain redundant. :-( >=20 >=20 >=20 >> 2. Design goal 2, perhaps say =93must=94 rather than =93do=94? >=20 > Yep. Will do. >=20 >=20 >=20 >> 3. In section 4 the author states the goal of stable IIDs within a >> given subnet. It may be better to say for a given prefix, given a >> renumbering process will change the prefix and with it the IID, >> though by loose language you might refer to it as the same subnet. >=20 > Will do. >=20 >=20 >=20 >=20 >> In response to recent discussion on 6man, I don=92t believe it=92s >> practical or desirable for a node to store addresses related to >> locations (networks) visited. I agree with the author that the >> static address per network should be generated statelessly. >=20 > Great. :-) >=20 > Thanks so much! Overall the document is in very good shape. Well done! Tim >=20 > Cheers, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 --Apple-Mail=_046325FD-7709-49FD-88CC-C3F62EC42B7C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 fgont@si6networks.com> = wrote:

Hi, Tim,

Thanks so much for your feedback! Please = find my comments in-line...

On 01/22/2014 10:05 PM, Tim Chown = wrote:
Issues:

1. In the discussion = in section 5 on the algorithm, it may be
desirable to suggest that = implementations allow a choice of IID
generation based on =91classic=92= SLAAC with EUI-64 or via this new
proposed method, with a default of = the new method.

This point is actually addressed by = the draft-ietf version for
deprecate-eui64 (which will not deprecate = eui64, but will specify the
default).

i.e., this document just = focuses on how you implement stable-privacy.
The draft-ietf version = of deprecate-eui64
(draft-ietf-6man-ipv6-defult-iids) seems like the = place to specify that
of having a knob to configure which method to = use...

I think Brian has cleared this = point up (issue to be described in a separate = text).



2. In the algorithm section, there is a comment that = interface names
MUST remain the same across boots or down/up events = for the stable
privacy address to remain stable. =

Strictly speaking, it says that Net_Iface MUST be = constant. Then
Appendix A discusses possible sources for = NetIface...


I have (admittedly some = time ago,
and in rare cases) seen Linux installations where network = interface
names can =91swap=92, thus changing the address in use on = the interface
under the proposed algorithm, whereas with existing = EUI64 SLAAC the
IIDs would remain the same even if the interface name = for a physical
interface changed. This is probably rather more likely = if replacing a
network card on motherboard with on-board NIC(s). =  Perhaps Fernando
can comment on whether this is a realistic = concern with modern OSes.

I think I was told that = this has been fixed in Linux . That said, we
don't require any = specific source for NetIface. For instance, you can
even use the = link-layer address (please see Section A.3), such that you
get the = same stability properties as EUI64 = SLAAC.
The rationale = for not requiring any specific source is that an
implementer know = better which source is more stable/convenient. Some
source might be = stable in one OS, but not in others. And = viceversa.

It does seem that each of = those sources listed in the Appendix may not be constant. That may of = course depend on hardware as well as OS.

I = guess there can be no 100% guarantee for all platforms, so the document = should note that, and the implications.  For example, the last para = in Section 1 could instead = say:

"This document specifies a method to = generate Interface Identifiers that, = subject to a constant/stable interface identifier being available, are = stable/constant for each network interface within each = prefix", or = something like that.

It should be noted that if no such table identifier = is available, a stable IID per prefix can't be guaranteed (unless stable = storage for visited prefixes is used, which has significant privacy = concerns as discussed earlier this = week...)

3. I assume the IID may/will vary for a different OS run = on the same
host, e.g. where the host is dual-boot, or where a new OS = installed
(or the same OS re-installed). A different OS may well use = a
different F(), given that=92s not specified.  With EUI-64, a = dual-boot
host would likely have the same address under either OS = (well, not
Windows any more=85).  This may be worth making = explicit.

This could be a pro or con, one might = say.

I guess we could add something along the lines = of:

"Since different implementation are likely to use different = values for
secret_key, and may also employ different PRNGs for F() = and different
surces for NetIface, we note that an a host that is = dual-boot or that is
reinstalled may result in different IPv6 = addresses for each OS = and/or
installation."?

That could = work.  Or you could maybe have a section or subsection that = documents cases where a stable IID can't be guaranteed.  The case = above is one, and dual-boot or a reinstalled OS is another?  Are = there other cases?

4. The draft talks (in one place in Section 3) about = stable privacy
addresses being allocated by DHCPv6; some further = discussion of how
this might be achieved may be useful given the = secret key is presumed
to be generated on and reside on the host, not = the DHCPv6 server.  Or
would this be described in a separate = future draft?

Yes, a future draft -- e.g. where the = algorithm is computed by the
DHCPv6 = server.

So one thing to consider here is = that unless the 'secret_key' is shared/copied between the host and the = DHCPv6 server, a subnet which changes to/from DHCPv6 to/from RAs for = address configuration will see the IID change.  Maybe this is a = third case of the above...


5. Design goal 1 might add = =93and same interface=94 for scenarios where a
host has two = interfaces in the same subnet (with the same prefix).
This scenario = is one that may cause =91interesting=92 effects with
addresses if = interface names swap and no Network_ID is used.

Will = do. (the seconds sentence already notes = this).



6. I=92d suggest not = mentioning MD5.

Yep. Will = do.




Nits:

1. Some = references are included multiple times, e.g. [RFC4941],
rather than = only at the first instance.

I will check this -- it = could be that I'm referring to different terms
of the same specs.... = or just me being plain redundant. :-(



2. Design goal 2, perhaps say =93must=94 rather than = =93do=94?

Yep. Will do.



3. In section 4 the author states the goal of stable IIDs = within a
given subnet. It may be better to say for a given prefix, = given a
renumbering process will change the prefix and with it the = IID,
though by loose language you might refer to it as the same = subnet.

Will do.




In response to recent discussion on 6man, I don=92t = believe it=92s
practical or desirable for a node to store addresses = related to
locations (networks) visited.  I agree with the = author that the
static address per network should be generated = statelessly.

Great. :-)

Thanks so = much!

Overall the document is in very = good shape. Well = done!

Tim


Cheers,
--
Fernando Gont
SI6 = Networks
e-mail: fgont@si6networks.com
PGP = Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E = 7492





= --Apple-Mail=_046325FD-7709-49FD-88CC-C3F62EC42B7C-- From brian.e.carpenter@gmail.com Fri Jan 24 20:59: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 D564B1A020B; Fri, 24 Jan 2014 20:59:36 -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 HGqAx2oYosRC; Fri, 24 Jan 2014 20:59:35 -0800 (PST) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7031A00C7; Fri, 24 Jan 2014 20:59:35 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id w10so3833021pde.6 for ; Fri, 24 Jan 2014 20:59:33 -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=Pvde+S1njwNoHC7l6LqXB71c3qaOMiw39zxzoGaGeao=; b=LzNDXJyLiojWPF1vpaJq2NTJWoNCzhqabCxQRW6MA1IEhKT2C7iZHcJ+5A3plmaDoy 8Q12VFWObeTTgIEGzWO7otSshG9AS0b6o9z6c+rm8KmWHW/Z0k86HgW8CD9xwDiAb6Ba S+HRpoYp/OlKsoAnZviRC3mn+8D67SiHK47a5eodvy0jyVDQZcdW86jBHWJC10G9bVSJ QJkFKbOyUhLlHp9pWprtqpFMooLJtf/l1vIM03DZcVGmVmNFT3eqFtfjb/SmNzqxaY6B QUsg7fd9+E2vexraH2lbC3nV7q3kFtDGjXU+500f2klteba4z3VmARuK0Sx9wOPIuIyl H0fg== X-Received: by 10.68.226.9 with SMTP id ro9mr18324792pbc.72.1390625973817; Fri, 24 Jan 2014 20:59:33 -0800 (PST) Received: from [192.168.178.23] (218.194.69.111.dynamic.snap.net.nz. [111.69.194.218]) by mx.google.com with ESMTPSA id nv7sm8718151pbc.31.2014.01.24.20.59.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Jan 2014 20:59:33 -0800 (PST) Message-ID: <52E344BE.1090904@gmail.com> Date: Sat, 25 Jan 2014 17:59:42 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pete Resnick Subject: Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT) References: <20140122192018.8692.82071.idtracker@ietfa.amsl.com> <52E02C0C.7080901@si6networks.com> <52E0322C.1000301@qti.qualcomm.com> <52E03DCB.4060101@gont.com.ar> <52E03F1D.3000307@innovationslab.net> <47E8B622-5F85-414A-B266-87B0C998E4CD@gmail.com> <52E05292.4000301@qti.qualcomm.com> <52E05577.4070204@qti.qualcomm.com> In-Reply-To: <52E05577.4070204@qti.qualcomm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man-chairs@tools.ietf.org, Brian Haberman , ipv6@ietf.org, Bob Hinden , Fernando Gont , draft-ietf-6man-stable-privacy-addresses@tools.ietf.org, Fernando Gont , The IESG 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, 25 Jan 2014 04:59:37 -0000 On 23/01/2014 12:34, Pete Resnick wrote: > On 1/22/14 5:31 PM, Bob Hinden wrote: >> Pete, >> >> On Jan 22, 2014, at 3:21 PM, Pete Resnick >> wrote: >> >> >>> On 1/22/14 5:16 PM, Bob Hinden wrote: >>> >>>> I have a question about what will happen if we agree to change it to >>>> Informational. Will this require a new IETF last call, or sending >>>> it back to the working group and starting the process over? >>>> >>>> >>> Nope. Going "down" in status just takes the wave of the IESG's magic >>> wand. 2026, 6.1.2, paragraph 5. >>> >> Good, then I don't object. Better to get it through the process than >> argue over the IETF label. >> >> If there aren't objections from the w.g. then we can do that. >> > > But there might be objections from others on the IESG. That's why I > ABSTAINed instead of DISCUSSed. I'm not willing to stand in the way > either, even though I think the standards track outcome is not the right > one. To wrap one more piece of rope around this axle, all IETF standards are optional; we set out to define a bunch of alternative standards for this particular area (IPv6 IIDs), and the market is left to choose. I don't really see why this causes Pete heartburn. But I do think that changing our practice now would be highly confusing to the said market. Especially if we end up with a standards track or BCP document that recommends using an Informational spec in preference to any of the Standards Track specs. Brian From brian.e.carpenter@gmail.com Sat Jan 25 12:39: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 1C92D1A0041; Sat, 25 Jan 2014 12:39:18 -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 25yLH1SaxTJV; Sat, 25 Jan 2014 12:39:16 -0800 (PST) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8B15F1A0040; Sat, 25 Jan 2014 12:39:16 -0800 (PST) Received: by mail-pb0-f49.google.com with SMTP id up15so4470060pbc.36 for ; Sat, 25 Jan 2014 12:39:15 -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=S73wORcpy4tmtm/70Gse5MyaAZXHyZVqsLBlwfbppvI=; b=TWuARh1t813zVUWKM/ULrYN1GdoevQMjv8EOsx3umqFydBe8F3gsV6Mw4B42lga/Ti QvIUAFcBdAuxgkXUwbQyo1WH0jpXh3rpALzBXoW6ttXiyHa4K7B+IlvtUTnawWAAlWAF YQeJRwF2SAPDjVjvRFly1Ol/qZe8CJBD51nbuW3CaDHBHyYpDihodzUiEVuZMpm20zPD 5s0gOlu2+02MiSACwbm30AXKPNxud6vAxJDGcHSmtHiJqwJSYk21/aYKBKelz09v5uiN jUYN89iIdh0lGKC0dUli8Ng4S6S/qAsFRC+g/TjgwyptZZaFbJ+fcNc1pKaMrrSA9tMN Za1Q== X-Received: by 10.68.88.161 with SMTP id bh1mr21572001pbb.49.1390682355120; Sat, 25 Jan 2014 12:39:15 -0800 (PST) Received: from [192.168.178.23] (250.199.69.111.dynamic.snap.net.nz. [111.69.199.250]) by mx.google.com with ESMTPSA id zc6sm41541157pab.18.2014.01.25.12.39.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 Jan 2014 12:39:14 -0800 (PST) Message-ID: <52E420EE.8090104@gmail.com> Date: Sun, 26 Jan 2014 09:39:10 +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: 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> <52DEB873.1080500@cs.tcd.ie> <52DEC5C8.7080903@si6networks.com> <52E130A7.5050102@cisco.com> <52E14FBB.1070901@si6networks.com> In-Reply-To: <52E14FBB.1070901@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, Lloyd Wood , Eliot Lear , The IESG , draft-ietf-6man-stable-privacy-addresses@tools.ietf.org, Stephen Farrell 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, 25 Jan 2014 20:39:18 -0000 On 24/01/2014 06:22, Fernando Gont wrote: ... > "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" Nobody could conceivably object to that, but I do wonder whether the statement "Secret keys should be kept secret" doesn't belong in a much more generic document than this one. Actually a BCP on pitfalls surrounding secret keys and how to protect them would be very valuable, but doesn't belong in this WG. Brian From fgont@si6networks.com Sat Jan 25 13:31: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 CDA4A1A005F; Sat, 25 Jan 2014 13:31: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 ZzcUxrFkS7VK; Sat, 25 Jan 2014 13:31: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 33B8A1A003A; Sat, 25 Jan 2014 13:31:14 -0800 (PST) Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W7Anp-0002M1-UX; Sat, 25 Jan 2014 22:30:10 +0100 Message-ID: <52E42C5F.9050601@si6networks.com> Date: Sat, 25 Jan 2014 18:27:59 -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: 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> <52DEB873.1080500@cs.tcd.ie> <52DEC5C8.7080903@si6networks.com> <52E130A7.5050102@cisco.com> <52E14FBB.1070901@si6networks.com> <52E420EE.8090104@gmail.com> In-Reply-To: <52E420EE.8090104@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, Lloyd Wood , Eliot Lear , The IESG , draft-ietf-6man-stable-privacy-addresses@tools.ietf.org, Stephen Farrell 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, 25 Jan 2014 21:31:18 -0000 On 01/25/2014 05:39 PM, Brian E Carpenter wrote: > On 24/01/2014 06:22, Fernando Gont wrote: > ... >> "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" > > Nobody could conceivably object to that, but I do wonder whether the > statement "Secret keys should be kept secret" doesn't belong in a much > more generic document than this one. Actually a BCP on pitfalls surrounding > secret keys and how to protect them would be very valuable, but doesn't > belong in this WG. I agree with you. I'd say I would have probably objected against adding this (with the argument "well, this should be obvious to everyone"). But then I recall having a conversation with a folk working on TCP SEQ randomization (using a similar scheme) for a popular OS, and apparently they were employing a constant secret key for all their systems. Hence, "sometimes it's not bad to clarify what you might deem as obvious". P.S.: And while at times it's easy to blame the guy doing the implementation, the truth is that at times the same folk is working on so much stuff that he kind of blindly implements whatever is in the spec, without much analysis. So... better fail on the safe side. 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 huitema@microsoft.com Sat Jan 25 16:53:52 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 B59D31A00BE; Sat, 25 Jan 2014 16:53:52 -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 U8n6FCM3sBOq; Sat, 25 Jan 2014 16:53:50 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id 8748D1A00BB; Sat, 25 Jan 2014 16:53:50 -0800 (PST) Received: from BLUPR03CA030.namprd03.prod.outlook.com (10.141.30.23) by SN2PR03MB061.namprd03.prod.outlook.com (10.255.175.149) with Microsoft SMTP Server (TLS) id 15.0.859.15; Sun, 26 Jan 2014 00:53:47 +0000 Received: from BN1AFFO11FD021.protection.gbl (2a01:111:f400:7c10::199) by BLUPR03CA030.outlook.office365.com (2a01:111:e400:879::23) with Microsoft SMTP Server (TLS) id 15.0.868.8 via Frontend Transport; Sun, 26 Jan 2014 00:53:47 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD021.mail.protection.outlook.com (10.58.52.81) with Microsoft SMTP Server (TLS) id 15.0.856.14 via Frontend Transport; Sun, 26 Jan 2014 00:53:46 +0000 Received: from TK5EX14MBXC301.redmond.corp.microsoft.com ([169.254.1.182]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0174.002; Sun, 26 Jan 2014 00:53:24 +0000 From: Christian Huitema To: Fernando Gont , Brian E Carpenter 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/6AgAAHZACAABetgIAAD+UAgALhwYCAACUMgIADW7wAgAANpICAADOKgA== Date: Sun, 26 Jan 2014 00:53:24 +0000 Message-ID: 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> <52E420EE.8090104@gmail.com> <52E42C5F.9050601@si6networks.com> In-Reply-To: <52E42C5F.9050601@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="Windows-1252" 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)(51704005)(199002)(189002)(50986001)(47976001)(80022001)(51856001)(6806004)(74706001)(66066001)(83322001)(47736001)(49866001)(33656001)(92566001)(65816001)(44976005)(77982001)(59766001)(94316002)(74502001)(74366001)(81816001)(47446002)(50466002)(92726001)(93516002)(74662001)(31966008)(79102001)(69226001)(85806002)(90146001)(56816005)(86362001)(20776003)(63696002)(47776003)(85306002)(54356001)(87266001)(56776001)(2656002)(74876001)(4396001)(81342001)(81686001)(76482001)(76796001)(76786001)(80976001)(23746002)(46102001)(53806001)(87936001)(77096001)(83072002)(54316002)(85852003)(93136001)(81542001)(55846006); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB061; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; InfoDomainNonexistentA:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 01039C93E4 X-OriginatorOrg: microsoft.com Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "ipv6@ietf.org" , Lloyd Wood , Eliot Lear , The IESG , "draft-ietf-6man-stable-privacy-addresses@tools.ietf.org" , Stephen Farrell 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, 26 Jan 2014 00:53:52 -0000 >> Nobody could conceivably object to that, but I do wonder whether the >> statement "Secret keys should be kept secret" doesn't belong in a much >> more generic document than this one. Actually a BCP on pitfalls surround= ing >> secret keys and how to protect them would be very valuable, but doesn't >> belong in this WG. > > I agree with you. > > I'd say I would have probably objected against adding this (with the > argument "well, this should be obvious to everyone"). But then I recall > having a conversation with a folk working on TCP SEQ randomization > (using a similar scheme) for a popular OS, and apparently they were > employing a constant secret key for all their systems. Hence, "sometimes > it's not bad to clarify what you might deem as obvious". That's actually a tradeoff in Fernando's algorithm. In order to guarantee = reuse of the same IPv6 address at the same location, the system only has to= remember the secret key. But if the secret key is disclosed to an attacker= , the attacker can predict the IPv6 address that will be used by that syste= m at any future location. There are other possible designs that don't make the same tradeoff. For exa= mple, systems could maintain a list of visited locations and associated IPv= 6 addresses. When they visit a location not in the list, they can pick a ra= ndom number for their IID. The system will require more memory, but will ha= ve the property that future addresses will be unpredictable, even if an att= acker manages to obtain the list of previously used addresses and locations= . -- Christian Huitema From alexandru.petrescu@gmail.com Mon Jan 27 02:56: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 7F9601A01D2 for ; Mon, 27 Jan 2014 02:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.084 X-Spam-Level: X-Spam-Status: No, score=-3.084 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, 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 cQL0tsP5luoh for ; Mon, 27 Jan 2014 02:56:40 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 056D81A017A for ; Mon, 27 Jan 2014 02:56:39 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s0RAuXno027247; Mon, 27 Jan 2014 11:56:33 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7CE41204F1A; Mon, 27 Jan 2014 11:56:39 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6E317204F08; Mon, 27 Jan 2014 11:56:39 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0RAuJj6002358; Mon, 27 Jan 2014 11:56:32 +0100 Message-ID: <52E63B52.3070004@gmail.com> Date: Mon, 27 Jan 2014 11:56:18 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ray Hunter Subject: Re: Update about draft-petrescu-ipv6-over-80211p-01.txt References: <52DBDCD3.6010600@gmail.com> <52E60967.9040206@globis.net> In-Reply-To: <52E60967.9040206@globis.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Romain KUNTZ , 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 10:56:42 -0000 Hi Ray, Thanks for the reply. Le 27/01/2014 08:23, Ray Hunter a écrit : > 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? There is a similarity and a discrepancy when comparing the low-power to the high mobility constraints of 6lowpans and vehicular networks: both would benefit if fewer messages were sent, and still vehicle networks are not so battery-limited as the sensors. > I realise that in a vehicular scenario, maintaining the mesh under > network may prove challenging. I think that is right. Maintaining a mesh under is challenging in the vehicular scenarios. I think RFC6775 has a form of distributing routes (router-to-router interactions) but I doubt it describes loop avoidance, which should be part of mesh under, right? The section 5.6 needs more explanation. Would you be interested? Also, this would be a typical IPv6-over-foo document, and such as maybe we would not need to describe too much routing/meshing detail. Alex > > 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 >> >> > From fgont@si6networks.com Mon Jan 27 06:00: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 C79FF1A022F; Mon, 27 Jan 2014 06:00:51 -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 xRDrbA50zkuz; Mon, 27 Jan 2014 06:00: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 64A381A022E; Mon, 27 Jan 2014 06:00:48 -0800 (PST) Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W7mjy-0003DL-1i; Mon, 27 Jan 2014 15:00:42 +0100 Message-ID: <52E65DE6.3010903@si6networks.com> Date: Mon, 27 Jan 2014 10:23:50 -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: Tim Chown Subject: Re: OPS-DIR review of draft-6man-stable-privacy-addresses-16 References: <52E0C6A8.3050503@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: 6man-chairs@tools.ietf.org, ops-dir@ietf.org, ipv6@ietf.org, draft-ietf-6man-stable-privacy-addresses.all@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, 27 Jan 2014 14:00:52 -0000 Hi, Tim, Thanks so much for your response! -- Please find mine in-line... On 01/24/2014 02:13 PM, Tim Chown wrote: >>> 2. In the algorithm section, there is a comment that interface names >>> MUST remain the same across boots or down/up events for the stable >>> privacy address to remain stable. >> >> Strictly speaking, it says that Net_Iface MUST be constant. Then >> Appendix A discusses possible sources for NetIface... [....] > It does seem that each of those sources listed in the Appendix may not > be constant. That may of course depend on hardware as well as OS. At the very least, I'd expect the MAC address to be constant. > I guess there can be no 100% guarantee for all platforms, so the > document should note that, and the implications. For example, the last > para in Section 1 could instead say: > > "This document specifies a method to generate Interface > Identifiers that, subject to a constant/stable interface identifier > being available, are stable/constant for each network interface within > each prefix", or something like that. I have no issues with adding this. Although I wonder if it really represents reality. In most systems, you can apply ACLs based on the interface name/index... so the lack of constant IDs for the interfaces you mean that you couldn't really apply such ACLs. If you still think that the aforementioned paragraph would help, I'd probably add it as: "This document specifies a method to generate Interface Identifiers that, subject to a stable interface identifier being available (see Appendix A), are stable for each network interface within each prefix" (I've just added a reference to Appendix A, and removed the term "constant", based on the discussions we have had for the ipv6-addressing-privacy I-D). >>> 3. I assume the IID may/will vary for a different OS run on the same >>> host, e.g. where the host is dual-boot, or where a new OS installed >>> (or the same OS re-installed). A different OS may well use a >>> different F(), given that’s not specified. With EUI-64, a dual-boot >>> host would likely have the same address under either OS (well, not >>> Windows any more…). This may be worth making explicit. >> >> This could be a pro or con, one might say. >> >> I guess we could add something along the lines of: >> >> "Since different implementation are likely to use different values for >> secret_key, and may also employ different PRNGs for F() and different >> surces for NetIface, we note that an a host that is dual-boot or that is >> reinstalled may result in different IPv6 addresses for each OS and/or >> installation."? > > That could work. Or you could maybe have a section or subsection that > documents cases where a stable IID can't be guaranteed. The case above > is one, and dual-boot or a reinstalled OS is another? Are there other > cases? Rather than enumerating the cases, I'd probably add a "disclaimer" in the Intro. How about this improved version of the text: "Since different implementation are likely to use different values for the secret_key parameter, and may also employ different PRNGs for F(), and different sources for the Net_Iface parameter, the addresses generated by this scheme should not expected to be constant across different operating system installations. For example, a host that is dual-boot or that is reinstalled may result in different IPv6 addresses for each OS and/or installation." >>> 4. The draft talks (in one place in Section 3) about stable privacy >>> addresses being allocated by DHCPv6; some further discussion of how >>> this might be achieved may be useful given the secret key is presumed >>> to be generated on and reside on the host, not the DHCPv6 server. Or >>> would this be described in a separate future draft? >> >> Yes, a future draft -- e.g. where the algorithm is computed by the >> DHCPv6 server. > > So one thing to consider here is that unless the 'secret_key' is > shared/copied between the host and the DHCPv6 server, a subnet which > changes to/from DHCPv6 to/from RAs for address configuration will see > the IID change. Maybe this is a third case of the above... I kind of think of DHCPv6 as a different world and "out of scope". But please let me know if you think otherwise... Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From rdroms.ietf@gmail.com Mon Jan 27 08:00: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 3A1551A0255 for ; Mon, 27 Jan 2014 08:00:57 -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 TCiw_v1F-_jK for ; Mon, 27 Jan 2014 08:00:55 -0800 (PST) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9729B1A0231 for ; Mon, 27 Jan 2014 08:00:55 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id k4so7647529qaq.29 for ; Mon, 27 Jan 2014 08:00:53 -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=fvnEupY/Nudn9qlV7nHfadf+oO1g81E4oqZYyN03DWk=; b=l/5cmmnGur9Vz18WjPOtWNK4GA0WurwfkWZUIC6NFjRLzFQeQE8CLT9Q5LPvU9H7aY rLQCUu30otHx7l7cJBBH9MPSSYfbHtT/2xvAHsFx5juk/GIuDyJzjP+DWbDDq1cPJy/t 0SG01+UxwE5dl/PFicUXpiSngk7V/pTINw5kx6tED9/GXmrB0AzG6GUEBNgSpabyoXY6 kDKD9qFRFy1tp7tb5ntm0qM034teAd9yHIPHdJDO47QMVeATEmuJY7BBjP5MOIEfPkxi wq1Pw2LAHGij+JsDf+4QRXU5e0TCtBl8XgK9NNYxbqCYmbnHo+7DGNcuLUy9R1qX/h4K 4AuA== X-Received: by 10.140.84.19 with SMTP id k19mr41434693qgd.98.1390838453289; Mon, 27 Jan 2014 08:00:53 -0800 (PST) Received: from [161.44.68.171] ([161.44.68.171]) by mx.google.com with ESMTPSA id h12sm8738669qge.0.2014.01.27.08.00.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Jan 2014 08:00:51 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: 6MAN WG Last Call: From: Ralph Droms In-Reply-To: <5B4E67C2-3278-4D7D-A509-219CBEFE2589@gmail.com> Date: Mon, 27 Jan 2014 11:00:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0FE05336-3B06-4566-B984-6A17E7267A3C@gmail.com> References: <5B4E67C2-3278-4D7D-A509-219CBEFE2589@gmail.com> To: 6man Chairs <6man-chairs@tools.ietf.org> X-Mailer: Apple Mail (2.1510) 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, 27 Jan 2014 16:00:57 -0000 (As the author) I support advancing this document to the IESG. - Ralph On Jan 16, 2014, at 9:40 AM 1/16/14, Bob Hinden = wrote: > This message starts a two week 6MAN Working Group on advancing: >=20 > Title: IPv6 Multicast Address Scopes > Author(s): R. Droms > Filename: draft-ietf-6man-multicast-scopes-02 > Pages: 5 > Date: 2013-11-11 >=20 > http://tools.ietf.org/html/draft-ietf-6man-multicast-scopes-02 >=20 > as a Proposed Standard. Substantive comments and statements of = support for advancing this document should be directed to the mailing = list. Editorial suggestions can be sent to the authors. This last call = will end on January 30th, 2014. >=20 > Regards, >=20 > Bob Hinden & Ole Tr=F8an >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From tjc@ecs.soton.ac.uk Mon Jan 27 09:11: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 833831A0384; Mon, 27 Jan 2014 09:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.756 X-Spam-Level: X-Spam-Status: No, score=-1.756 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_NEUTRAL=0.779] 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 R_hPPf7asUOJ; Mon, 27 Jan 2014 09:11:50 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8781A037C; Mon, 27 Jan 2014 09:11:50 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s0RHBiaI028143; Mon, 27 Jan 2014 17:11:44 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s0RHBiaI028143 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1390842704; bh=6w8TNTcLwqOj1Eq1fKNtJwpl9PE=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=tLZTITVAXnHlUrwVuwdF59s84CbuLhYxslb2VIvearM41jS9n9hZwxI0RIbYbU/oS rdCSJd0anq7nMNbGLGFZn4IHbTMI/v2T5BFFOFFIgva1eDiFCMjYHHc/l9jiSUcIdV 0hr2FxV5Bi5uslhuE5dgX22TNgUrdODrXvNii+Mo= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id q0QHBi0959646152YC ret-id none; Mon, 27 Jan 2014 17:11:44 +0000 Received: from dhcp-161-19.wireless.soton.ac.uk (dhcp-161-19.wireless.soton.ac.uk [152.78.161.19] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s0RHBgp6023807 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Jan 2014 17:11:42 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: OPS-DIR review of draft-6man-stable-privacy-addresses-16 From: Tim Chown In-Reply-To: <52E65DE6.3010903@si6networks.com> Date: Mon, 27 Jan 2014 17:11:04 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <52E0C6A8.3050503@si6networks.com> <52E65DE6.3010903@si6networks.com> <6FB21B43-0001-46D7-A57E-2359D819BC4A@ecs.soton.ac.uk> To: Fernando Gont X-Mailer: Apple Mail (2.1510) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q0QHBi095964615200; tid=q0QHBi0959646152YC; client=relay,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s0RHBiaI028143 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: 6man-chairs@tools.ietf.org, ops-dir@ietf.org, ipv6@ietf.org, draft-ietf-6man-stable-privacy-addresses.all@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, 27 Jan 2014 17:11:54 -0000 Hi, On 27 Jan 2014, at 13:23, Fernando Gont wrote: > Hi, Tim, >=20 > Thanks so much for your response! -- Please find mine in-line... >=20 > On 01/24/2014 02:13 PM, Tim Chown wrote: >>>> 2. In the algorithm section, there is a comment that interface = names >>>> MUST remain the same across boots or down/up events for the stable >>>> privacy address to remain stable. >>>=20 >>> Strictly speaking, it says that Net_Iface MUST be constant. Then >>> Appendix A discusses possible sources for NetIface... > [....] >> It does seem that each of those sources listed in the Appendix may = not >> be constant. That may of course depend on hardware as well as OS. >=20 > At the very least, I'd expect the MAC address to be constant. Yes, as much as it would be for classic EUI64 SLAAC. =20 >> I guess there can be no 100% guarantee for all platforms, so the >> document should note that, and the implications. For example, the = last >> para in Section 1 could instead say: >>=20 >> "This document specifies a method to generate Interface >> Identifiers that, subject to a constant/stable interface identifier >> being available, are stable/constant for each network interface = within >> each prefix", or something like that. >=20 > I have no issues with adding this. Although I wonder if it really > represents reality. In most systems, you can apply ACLs based on the > interface name/index... so the lack of constant IDs for the interfaces > you mean that you couldn't really apply such ACLs. >=20 > If you still think that the aforementioned paragraph would help, I'd > probably add it as: >=20 > "This document specifies a method to generate Interface > Identifiers that, subject to a stable interface identifier being > available (see Appendix A), are stable for each network interface > within each prefix" >=20 > (I've just added a reference to Appendix A, and removed the term > "constant", based on the discussions we have had for the > ipv6-addressing-privacy I-D). So I think the thing here is that the IID can't be guaranteed to be = stable per prefix, because there are factors that may cause it to = change. The only way to be sure it's stable per prefix is to store the = IID used per prefix, or to find some stateless generation method for = which there can be no change. Storing the per-prefix IIDs essentially = puts a permanent list of all addresses the device has ever used into = persistent storage on the device. >>>> 3. I assume the IID may/will vary for a different OS run on the = same >>>> host, e.g. where the host is dual-boot, or where a new OS installed >>>> (or the same OS re-installed). A different OS may well use a >>>> different F(), given that=92s not specified. With EUI-64, a = dual-boot >>>> host would likely have the same address under either OS (well, not >>>> Windows any more=85). This may be worth making explicit. >>>=20 >>> This could be a pro or con, one might say. >>>=20 >>> I guess we could add something along the lines of: >>>=20 >>> "Since different implementation are likely to use different values = for >>> secret_key, and may also employ different PRNGs for F() and = different >>> surces for NetIface, we note that an a host that is dual-boot or = that is >>> reinstalled may result in different IPv6 addresses for each OS = and/or >>> installation."? >>=20 >> That could work. Or you could maybe have a section or subsection = that >> documents cases where a stable IID can't be guaranteed. The case = above >> is one, and dual-boot or a reinstalled OS is another? Are there = other >> cases? >=20 > Rather than enumerating the cases, I'd probably add a "disclaimer" in > the Intro. How about this improved version of the text: >=20 > "Since different implementation are likely to use different values for > the secret_key parameter, and may also employ different PRNGs for > F(), and different sources for the Net_Iface parameter, the > addresses generated by this scheme should not expected to be constant > across different operating system installations. For example, a host > that is dual-boot or that is reinstalled may result in different IPv6 > addresses for each OS and/or installation." Well, I'm not making this as a blocking comment, I'm just suggesting = that a (sub)section that itemises the reasons that the "stable" address = per prefix may not be stable would be a useful thing to have in the = table of contents. =20 There may be some use cases where an administrator assumes the IID is = stable per prefix, when it may not be. Someone that doesn't know how = the IID generation function works, but just sees the "Configure stable = privacy address" option in a menu, might not realise that the IID can = change under some circumstances. Again, I'm happy to go with your final = call on this, but just raising it to be sure you've thought about it. >>>> 4. The draft talks (in one place in Section 3) about stable privacy >>>> addresses being allocated by DHCPv6; some further discussion of how >>>> this might be achieved may be useful given the secret key is = presumed >>>> to be generated on and reside on the host, not the DHCPv6 server. = Or >>>> would this be described in a separate future draft? >>>=20 >>> Yes, a future draft -- e.g. where the algorithm is computed by the >>> DHCPv6 server. >>=20 >> So one thing to consider here is that unless the 'secret_key' is >> shared/copied between the host and the DHCPv6 server, a subnet which >> changes to/from DHCPv6 to/from RAs for address configuration will see >> the IID change. Maybe this is a third case of the above... >=20 > I kind of think of DHCPv6 as a different world and "out of scope". But > please let me know if you think otherwise... The title of the document is clearly stating this is a SLAAC method, so = there's no need to discuss DHCPv6. But I would say that some networks = will run SLAAC, and some DHCPv6, and that choice might change over time, = so there is an issue as to whether the secret_key is held only on the = host, only on the DHCPv6 server, or if there's some method to share = them. Another thing to consider operationally is the scope of where the stable = privacy address is used. If you really wanted to guarantee a stable = privacy address per subnet within a single enterprise, and you had = administrative/policy control of the hosts, you might want to have a = configuration knob to turn on storage of per-prefix IIDs for prefixes = belonging to that site. Similarly some administrators might turn off = IPv6 Privacy Addresses where they have managed devices within an = enterprise to ensure their devices use stable IPv6 source addresses. I = guess this type of consideration is probably best aimed at your other = usage draft though... Tim > Thanks! >=20 > Cheers, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 From huitema@microsoft.com Mon Jan 27 09:49: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 99C5B1A0290; Mon, 27 Jan 2014 09:49:51 -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 EolJkTDKq5zQ; Mon, 27 Jan 2014 09:49:49 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0157.outbound.protection.outlook.com [207.46.163.157]) by ietfa.amsl.com (Postfix) with ESMTP id 6140C1A0256; Mon, 27 Jan 2014 09:49:49 -0800 (PST) Received: from BY2PR03CA036.namprd03.prod.outlook.com (10.242.234.157) by BY2PR03MB091.namprd03.prod.outlook.com (10.255.241.159) with Microsoft SMTP Server (TLS) id 15.0.859.15; Mon, 27 Jan 2014 17:49:45 +0000 Received: from BN1AFFO11FD034.protection.gbl (2a01:111:f400:7c10::170) by BY2PR03CA036.outlook.office365.com (2a01:111:e400:2c2c::29) with Microsoft SMTP Server (TLS) id 15.0.859.15 via Frontend Transport; Mon, 27 Jan 2014 17:49:45 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD034.mail.protection.outlook.com (10.58.52.158) with Microsoft SMTP Server (TLS) id 15.0.856.14 via Frontend Transport; Mon, 27 Jan 2014 17:49:44 +0000 Received: from TK5EX14MBXC303.redmond.corp.microsoft.com ([169.254.3.26]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0174.002; Mon, 27 Jan 2014 17:49:07 +0000 From: Christian Huitema To: Tim Chown , Fernando Gont Subject: RE: OPS-DIR review of draft-6man-stable-privacy-addresses-16 Thread-Topic: OPS-DIR review of draft-6man-stable-privacy-addresses-16 Thread-Index: AQHPF9d7xlCP8xsCSk2rn/+NsHQ8GpqR7CwAgAIzVwCABHbWAIAAP30AgAAJA5A= Date: Mon, 27 Jan 2014 17:49:06 +0000 Message-ID: References: <52E0C6A8.3050503@si6networks.com> <52E65DE6.3010903@si6networks.com> <6FB21B43-0001-46D7-A57E-2359D819BC4A@ecs.soton.ac.uk> 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)(83322001)(51856001)(76482001)(44976005)(94316002)(6806004)(87266001)(56776001)(2656002)(87936001)(74502001)(47446002)(86362001)(74662001)(65816001)(54316002)(46102001)(31966008)(33656001)(47736001)(80022001)(66066001)(50986001)(47976001)(49866001)(85306002)(79102001)(90146001)(74876001)(46406003)(74366001)(81686001)(81542001)(69226001)(76786001)(76796001)(77096001)(23726002)(4396001)(83072002)(85852003)(81342001)(80976001)(63696002)(54356001)(47776003)(20776003)(53806001)(77982001)(55846006)(59766001)(92566001)(93516002)(81816001)(50466002)(92726001)(93136001)(56816005)(74706001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB091; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; InfoDomainNonexistentMX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0104247462 X-OriginatorOrg: microsoft.com Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "ops-dir@ietf.org" , "ipv6@ietf.org" , "draft-ietf-6man-stable-privacy-addresses.all@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, 27 Jan 2014 17:49:51 -0000 > So I think the thing here is that the IID can't be guaranteed to be stabl= e per prefix, because there are factors that may cause it to change. The o= nly way to be sure it's stable per prefix is to store the IID used per pref= ix, or to find some stateless generation method for which there can be no c= hange. Storing the per-prefix IIDs essentially puts a permanent list of all= addresses the device has ever used into persistent storage on the device. In fact, the draft already has some text about remembering DAD collisions: In order to mitigate thi= s potential problem, nodes MAY record the DAD_Counter value employed for a specific {Prefix, Net_Iface, Network_ID} tuple in non-volatile memory, such that the same DAD_Counter value is employed when configuring an address for the same Prefix and subnet at any other point in time. This can be a baby step towards "a permanent list of all addresses the devi= ce has ever used..." But then, we have to wonder whether we really need to = guarantee that the address will remain constant for all locations that the = device visits. In practice, it feels like the "stable address" property is = mostly needed in the "home base" of the device, for example the corporate n= etwork if the device is registered in one. On the other hand, I don't think= many will object if their device gets a different address each time they v= isit the same airport bar... -- Christian Huitema =20 From tjc@ecs.soton.ac.uk Mon Jan 27 11:10: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 9FABC1A0239; Mon, 27 Jan 2014 11:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.756 X-Spam-Level: X-Spam-Status: No, score=-1.756 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_NEUTRAL=0.779] 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 XTLRI7si_DtA; Mon, 27 Jan 2014 11:10:53 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 45AE91A007C; Mon, 27 Jan 2014 11:10:53 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s0RJAmll031851; Mon, 27 Jan 2014 19:10:48 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s0RJAmll031851 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1390849848; bh=PfMDkB9huRVChx69l4CgwTZ6x2A=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=hjSJpf/XY+nncnyqD5Mf76OiCfWhWFmILDFl4OFeXPjBqd0wd61mzqBYz9862jen9 Pzodp4qmK9KRZEZd969qE7dXS9Q50QUylrxcS75GdkGqGwsYx9f9WAvYMt+Hs7ox6k z/DYcLH0AWxU68aCFOefALUJRdG/EvPY2MskNNR4= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id q0QJAm0959647084q8 ret-id none; Mon, 27 Jan 2014 19:10:48 +0000 Received: from [192.168.1.108] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s0RJ9R8V022277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Jan 2014 19:09:28 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: OPS-DIR review of draft-6man-stable-privacy-addresses-16 From: Tim Chown In-Reply-To: Date: Mon, 27 Jan 2014 19:09:31 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <52E0C6A8.3050503@si6networks.com> <52E65DE6.3010903@si6networks.com> <6FB21B43-0001-46D7-A57E-2359D819BC4A@ecs.soton.ac.uk> To: Christian Huitema X-Mailer: Apple Mail (2.1827) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q0QJAm095964708400; tid=q0QJAm0959647084q8; client=relay,ipv6; mail=; rcpt=; nrcpt=6:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s0RJAmll031851 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Fernando Gont , "ops-dir@ietf.org" , "ipv6@ietf.org" , "draft-ietf-6man-stable-privacy-addresses.all@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, 27 Jan 2014 19:10:55 -0000 Hi, On 27 Jan 2014, at 17:49, Christian Huitema = wrote: >> So I think the thing here is that the IID can't be guaranteed to be = stable per prefix, because there are factors that may cause it to = change. The only way to be sure it's stable per prefix is to store the = IID used per prefix, or to find some stateless generation method for = which there can be no change. Storing the per-prefix IIDs essentially = puts a permanent list of all addresses the device has ever used into = persistent storage on the device. >=20 > In fact, the draft already has some text about remembering DAD = collisions: >=20 > In order to mitigate = this potential problem, > nodes MAY record the DAD_Counter value employed for a specific > {Prefix, Net_Iface, Network_ID} tuple in non-volatile memory, such > that the same DAD_Counter value is employed when configuring an > address for the same Prefix and subnet at any other point in time. >=20 > This can be a baby step towards "a permanent list of all addresses the = device has ever used..." But then, we have to wonder whether we really = need to guarantee that the address will remain constant for all = locations that the device visits. In practice, it feels like the "stable = address" property is mostly needed in the "home base" of the device, for = example the corporate network if the device is registered in one. On the = other hand, I don't think many will object if their device gets a = different address each time they visit the same airport bar... I agree with the likely use case. I suggested something to consider = along those lines for Fernando=92s related draft. Tim= From internet-drafts@ietf.org Mon Jan 27 13:53: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 851D61A03B1; Mon, 27 Jan 2014 13:53:10 -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 J0BdUeeLNbsZ; Mon, 27 Jan 2014 13:53:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F9A1A03D8; Mon, 27 Jan 2014 13:53:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-stable-privacy-addresses-17.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140127215305.12533.61422.idtracker@ietfa.amsl.com> Date: Mon, 27 Jan 2014 13:53:05 -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: Mon, 27 Jan 2014 21:53:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : A Method for Generating Semantically Opaque Inter= face Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) Author : Fernando Gont Filename : draft-ietf-6man-stable-privacy-addresses-17.txt Pages : 19 Date : 2014-01-27 Abstract: This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware addresses (e.g., IEEE LAN MAC addresses), such that the benefits of stable addresses can be achieved without sacrificing the privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique- local addresses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-stable-privacy-addresses= -17 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 internet-drafts@ietf.org Mon Jan 27 13:53: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 D03831A03E5 for ; Mon, 27 Jan 2014 13:53:11 -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 srEnUhczkLRa; Mon, 27 Jan 2014 13:53:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F31901A02DC; Mon, 27 Jan 2014 13:53:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: 6man-chairs@tools.ietf.org, draft-ietf-6man-stable-privacy-addresses@tools.ietf.org, ipv6@ietf.org, brian@innovationslab.net, stephen.farrell@cs.tcd.ie, brian@innovationslab.net Subject: New Version Notification - draft-ietf-6man-stable-privacy-addresses-17.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140127215305.12533.54039.idtracker@ietfa.amsl.com> Date: Mon, 27 Jan 2014 13:53:05 -0800 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: Mon, 27 Jan 2014 21:53:12 -0000 A new version (-17) has been submitted for draft-ietf-6man-stable-privacy-a= ddresses: http://www.ietf.org/internet-drafts/draft-ietf-6man-stable-privacy-addresse= s-17.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-stable-privacy-addresses= -17 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. IETF Secretariat. From fgont@si6networks.com Mon Jan 27 14:07: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 0EC611A0093; Mon, 27 Jan 2014 14:07:45 -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 Rhavt6hnqiQD; Mon, 27 Jan 2014 14:07: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 B3BB91A0068; Mon, 27 Jan 2014 14:07:41 -0800 (PST) Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W7uK6-0006R2-GE; Mon, 27 Jan 2014 23:06:30 +0100 Message-ID: <52E6D7E1.4090007@si6networks.com> Date: Mon, 27 Jan 2014 19:04: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: Tim Chown Subject: Re: OPS-DIR review of draft-6man-stable-privacy-addresses-16 References: <52E0C6A8.3050503@si6networks.com> <52E65DE6.3010903@si6networks.com> <6FB21B43-0001-46D7-A57E-2359D819BC4A@ecs.soton.ac.uk> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: 6man-chairs@tools.ietf.org, ops-dir@ietf.org, ipv6@ietf.org, draft-ietf-6man-stable-privacy-addresses.all@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, 27 Jan 2014 22:07:45 -0000 Hi, Tim, On 01/27/2014 02:11 PM, Tim Chown wrote: [....] >> >> "This document specifies a method to generate Interface Identifiers >> that, subject to a stable interface identifier being available (see >> Appendix A), are stable for each network interface within each >> prefix" >> >> (I've just added a reference to Appendix A, and removed the term >> "constant", based on the discussions we have had for the >> ipv6-addressing-privacy I-D). > > So I think the thing here is that the IID can't be guaranteed to be > stable per prefix, because there are factors that may cause it to > change. The only way to be sure it's stable per prefix is to store > the IID used per prefix, or to find some stateless generation method > for which there can be no change. Storing the per-prefix IIDs > essentially puts a permanent list of all addresses the device has > ever used into persistent storage on the device. Well, strictly speaking, you can never guarantee an IID to be stable: since you're required to do DAD, even with the traditional SLAAC you might find a collision. Even if you record the addresses, the same applies. My take is that, one way or another, you can always find some stable-enough Net_Iface parameters that leads to a pragmatically stable IID. >> Rather than enumerating the cases, I'd probably add a "disclaimer" >> in the Intro. How about this improved version of the text: >> >> "Since different implementation are likely to use different values >> for the secret_key parameter, and may also employ different PRNGs >> for F(), and different sources for the Net_Iface parameter, the >> addresses generated by this scheme should not expected to be >> constant across different operating system installations. For >> example, a host that is dual-boot or that is reinstalled may result >> in different IPv6 addresses for each OS and/or installation." > > Well, I'm not making this as a blocking comment, I'm just suggesting > that a (sub)section that itemises the reasons that the "stable" > address per prefix may not be stable would be a useful thing to have > in the table of contents. My take is that such section is doomed to have an errata. :-) Thus why I suggest a clarification of "don't expect the IID to remain constant across OS installations... even if re-installation of the same OS). Having some sort of stable Net_iface is a requirement for this spec. It doesn't matter which one you choose... as long as it is stable. >>>>> 4. The draft talks (in one place in Section 3) about stable >>>>> privacy addresses being allocated by DHCPv6; some further >>>>> discussion of how this might be achieved may be useful given >>>>> the secret key is presumed to be generated on and reside on >>>>> the host, not the DHCPv6 server. Or would this be described >>>>> in a separate future draft? >>>> >>>> Yes, a future draft -- e.g. where the algorithm is computed by >>>> the DHCPv6 server. >>> >>> So one thing to consider here is that unless the 'secret_key' is >>> shared/copied between the host and the DHCPv6 server, a subnet >>> which changes to/from DHCPv6 to/from RAs for address >>> configuration will see the IID change. Maybe this is a third >>> case of the above... >> >> I kind of think of DHCPv6 as a different world and "out of scope". >> But please let me know if you think otherwise... > > The title of the document is clearly stating this is a SLAAC method, > so there's no need to discuss DHCPv6. But I would say that some > networks will run SLAAC, and some DHCPv6, and that choice might > change over time, so there is an issue as to whether the secret_key > is held only on the host, only on the DHCPv6 server, or if there's > some method to share them. So far, there's nothing like that. And while this document mentions DHCPv6, the idea is "this might be ported to DHCPv6 in some future document". > Another thing to consider operationally is the scope of where the > stable privacy address is used. If you really wanted to guarantee a > stable privacy address per subnet within a single enterprise, and you > had administrative/policy control of the hosts, you might want to > have a configuration knob to turn on storage of per-prefix IIDs for > prefixes belonging to that site. Similarly some administrators might > turn off IPv6 Privacy Addresses where they have managed devices > within an enterprise to ensure their devices use stable IPv6 source > addresses. I guess this type of consideration is probably best aimed > at your other usage draft though... Agreed. FWIW, I should say that previous attempts to do that for SLAAC have failed (e.g. ). 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 stephen.farrell@cs.tcd.ie Tue Jan 28 17:58: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 C33FA1A048B; Tue, 28 Jan 2014 17:58:50 -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 2_NYIddP6wQf; Tue, 28 Jan 2014 17:58:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65BA81A0483; Tue, 28 Jan 2014 17:58:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Stephen Farrell" To: The IESG Subject: Stephen Farrell's No Objection on draft-ietf-6man-stable-privacy-addresses-17: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140129015849.4189.40402.idtracker@ietfa.amsl.com> Date: Tue, 28 Jan 2014 17:58:49 -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: Wed, 29 Jan 2014 01:58:51 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-6man-stable-privacy-addresses-17: 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: ---------------------------------------------------------------------- Thanks for those changes. One new comment. It'd be better to reference HMAC-SHA1 and HMAC-SHA256 as the examples and not SHA1 and SHA256. There are relevant security differences between those, = depending on how you provide and process the inputs to F(). (I've not tried to figure out if ther're significant here, but the HMAC flavours are just better and if you did use them then I'd not even need to think about it:-) If you're not happy to do that then rather than say that SHA1 or SHA256 can be used "for" F(), it'd be better to say that F() = can be "baeed upon" SHA1, as that'd encompass HMAC-SHA1 or HMAC-SHA256. From wwwrun@rfc-editor.org Wed Jan 29 09:30: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 09F591A037E; Wed, 29 Jan 2014 09:30:51 -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 Qb5UaXCHauMc; Wed, 29 Jan 2014 09:30:49 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id A80601A036A; Wed, 29 Jan 2014 09:30:49 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D475C7FC17B; Wed, 29 Jan 2014 09:30:44 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 7112 on Implications of Oversized IPv6 Header Chains From: rfc-editor@rfc-editor.org Message-Id: <20140129173044.D475C7FC17B@rfc-editor.org> Date: Wed, 29 Jan 2014 09:30:44 -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: Wed, 29 Jan 2014 17:30:51 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7112 Title: Implications of Oversized IPv6 Header Chains Author: F. Gont, V. Manral, R. Bonica Status: Standards Track Stream: IETF Date: January 2014 Mailbox: fgont@si6networks.com, vishwas@ionosnetworks.com, rbonica@juniper.net Pages: 8 Characters: 15897 Updates: RFC 2460 I-D Tag: draft-ietf-6man-oversized-header-chain-09.txt URL: http://www.rfc-editor.org/rfc/rfc7112.txt The IPv6 specification allows IPv6 Header Chains of an arbitrary size. The specification also allows options that can, in turn, extend each of the headers. In those scenarios in which the IPv6 Header Chain or options are unusually long and packets are fragmented, or scenarios in which the fragment size is very small, the First Fragment of a packet may fail to include the entire IPv6 Header Chain. This document discusses the interoperability and security problems of such traffic, and updates RFC 2460 such that the First Fragment of a packet is required to contain the entire IPv6 Header Chain. 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 rdroms.ietf@gmail.com Wed Jan 29 10:24: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 A86321A03D6 for ; Wed, 29 Jan 2014 10:24: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 Z2i554vIdXQr for ; Wed, 29 Jan 2014 10:24:22 -0800 (PST) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 86DF11A03CB for ; Wed, 29 Jan 2014 10:24:22 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id n7so3373591qcx.30 for ; Wed, 29 Jan 2014 10:24: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=s9iCtpZ3DQJawlx8k6sxOVr9VX4AzqwbyUfKsdGrJws=; b=MpCl/q8PhUZcKulnprggoYouDiqpmE6zvwvvRj6o57e6+cvXB2MipMWwkZfuNjayGK 7smgh4doDAAUx8EoOYcppndcudw8Fkwx4aJ2OkAH2kT96XqCDuEtEDZ3HqNuq6oaL6cK AUrfmfIeFgj1mLS2lJJ1ksada63S82rD7AsWrMvdUCbWFMSG01hCRaoLWimLv5EaplXk Do954fxnzaFIfs0YjFi7FVr34NgQDIuWlMgUxjI9EGQxz5NPxpeYtIppUtXwohVFHrp8 5RvM5y37K3Po36ikt9NEcPHO9f6/ZuOd6rvwRTLruVFpPl5BpekWhFHNTaiEoHCcl17J PjBw== X-Received: by 10.140.108.229 with SMTP id j92mr13884953qgf.7.1391019859482; Wed, 29 Jan 2014 10:24:19 -0800 (PST) Received: from ?IPv6:2001:4830:16b1:1:adcc:b047:711a:db0e? ([2001:4830:16b1:1:adcc:b047:711a:db0e]) by mx.google.com with ESMTPSA id h12sm4555156qge.0.2014.01.29.10.24.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Jan 2014 10:24:18 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt From: Ralph Droms In-Reply-To: Date: Wed, 29 Jan 2014 13:24:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2C582C86-A609-43BD-958F-0EF3177485C5@gmail.com> References: <20131021233827.32495.34424.idtracker@ietfa.amsl.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1510) Cc: IETF IPv6 Mailing List , draft-ietf-6man-resilient-rs 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, 29 Jan 2014 18:24:24 -0000 On Jan 23, 2014, at 1:52 PM 1/23/14, Lorenzo Colitti = wrote: > On Thu, Jan 23, 2014 at 9:48 AM, Ralph Droms = wrote: > > This may be difficult to specify correctly. Specifically, it may be = hard to distinguish something that is being deprecated by the network = (e.g., an RA whose lifetime is counting down because it comes from a PD) = from an RA that is about to expire. >=20 > Might not be necessary to differentiate. Regardless of why the prefix = lifetime expired and whether the host has configured other , the host = will likely want to send periodic RSs in case a new prefix becomes = available and "unsolicited multicast Router Advertisements are never = sent" implies no RA to announce new prefixes. >=20 > That's true, but then you get into Erik's concern that whenever a host = sees that $SOMETHING is about to expire then it sends out an RS with = exponential backoff (until what? until it gets an RA - any RA, from = anyone?). >=20 > The concern is that basically ends up with hosts sending RSes all the = time - in other words, you implement dynamic reconfiguration via = polling. This is not necessarily a good use of hosts' CPU and battery = resources. You and I are pretty much in agreement here. I'm not trying to argue in = favor of sending RSes all the time. I'm just making the observation = that the basic assumptions lead to the use of periodic RSes. I don't = see that solution as an improvement over periodic RAs. - Raph >=20 > I do think that nodes should be free to send RSes if they so choose, = and I think we should say that a host MAY do so in this draft, but I = don't think we should attempt to design an architecture that depends on = polling. >=20 > Any objection to saying that hosts MAY send RSes when they want to = refresh information (e.g., when it's about to expire)? From ek@google.com Wed Jan 29 11:35: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 D17A11A02C7 for ; Wed, 29 Jan 2014 11:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 Agntv_Sanjxv for ; Wed, 29 Jan 2014 11:35:06 -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 0E4D11A029B for ; Wed, 29 Jan 2014 11:35:05 -0800 (PST) Received: by mail-qa0-f47.google.com with SMTP id j5so3088118qaq.34 for ; Wed, 29 Jan 2014 11:35:03 -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:content-transfer-encoding; bh=ydv8BQKMDBQiYu+JoAiTzelRx345BDMKTcVXBDANeOw=; b=e0tktjq5MfxEBjs9SDvbx18GWkvx9Jo8fkay7wI+TcsT5y3FgMyqkog6qbGTOxumN6 k39yTL6PvHD7o6RGgtP+o6CbMWpagWveXEH6EVNjhhU0vXElVDIpF66HC7qk1AtzbH5m 3LMIE3UYIjXaBD7qQ5ZaJIhqC3qdt4oRyBaY07yGhZpC4V8wdMeu0vAfm5gTC5c3E1Qk XAgJZ0gpOJKNGT/tV44burVQASSUuKVqphOHYIVLG3mVdUScFObj7ekLJBAfW38x/O9e BkuJq87fGOKfCg7qDLYBm3mcxqJ6Dmb3xzN2I/XpSWLxLHh4erEb3MudJvfSU/ieGXW5 ztQA== 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:content-transfer-encoding; bh=ydv8BQKMDBQiYu+JoAiTzelRx345BDMKTcVXBDANeOw=; b=eT2e0b7/2DmSPZgn0jA8uCEPZ8vRqiXZO38esDKNS+BtpKGojknkh7CH9TreHHmJ51 9KMoC57qKFEbyV57KfHcY12WWfihrkDT+Zew4cUeZ26w+mNLVdRL7EadmOs4fDdNpM4v d2EceM0wXfgrpuVySmRwqc88YhI8RukinQ8wLADbgmcaTsYAAzZ5jrPHowUOmh8jpFpT ph2Itz3LPgXhafh2153MlOe5tADBonv9HXYjxS7amy88iDDR7k3Szpmr6etq954SQEMF kgwmFhEPvh+jAZmY8oAl/BLU1A5oI+I5T+iyK67aGN3gmICEWMK2nvUzaooXmDyn71QJ E46A== X-Gm-Message-State: ALoCoQnKnKtp3DKQTM3nsptcKKqjE90Z7H4hoXCj6mdNH8Fng9O6gK2DxU/3AUNE4Vyos8xnc6o7cbxE4xpC3NmsE5aL4g+ZLTcpxNc/dz6Ay5HqNSImKJXz9zX2ZPOp8DeJKjf+WD+G6+SMZKQ45e4drATca/xa/8zduGcfPydRwZawT9oJMwFDqdnj4XenuY1Vs78Gfybk X-Received: by 10.229.213.194 with SMTP id gx2mr15264337qcb.16.1391024102948; Wed, 29 Jan 2014 11:35:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.82.141 with HTTP; Wed, 29 Jan 2014 11:34:42 -0800 (PST) In-Reply-To: <6299FD64-01A9-4F19-B271-9891AFCA3269@gmail.com> References: <20131021233827.32495.34424.idtracker@ietfa.amsl.com> <6299FD64-01A9-4F19-B271-9891AFCA3269@gmail.com> From: Erik Kline Date: Wed, 29 Jan 2014 11:34:42 -0800 Message-ID: Subject: Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt To: Ralph Droms Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-6man-resilient-rs@tools.ietf.org, IETF IPv6 Mailing 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: Wed, 29 Jan 2014 19:35:08 -0000 > A host on a multicast-capable link on which "unsolicited multicast Router= Advertisements are never sent" will have to use the same transmission beha= vior as a host on a non-multicast-capable link, so that the host can learn = of changes in the link prefixes in a timely fashion. Not necessarily. Consider the situation in a which a router responds to multicast RSs with unicast RAs. The host may in fact continue to receive unicast RAs periodically. From nordmark@acm.org Wed Jan 29 22:20: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 92AFD1A04E3 for ; Wed, 29 Jan 2014 22:20:42 -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 OD40NQ1rjEyq for ; Wed, 29 Jan 2014 22:20:41 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAEB1A041A for ; Wed, 29 Jan 2014 22:20:41 -0800 (PST) Received: from [10.0.1.44] (184-23-158-201.dsl.dynamic.sonic.net [184.23.158.201]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s0U6KUxd002113 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 29 Jan 2014 22:20:31 -0800 Message-ID: <52E9EF2D.9050402@acm.org> Date: Wed, 29 Jan 2014 22:20:29 -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: 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> In-Reply-To: <01DC3532-C73A-4644-A323-04BE6231AADA@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;gAkCnnaJ4xGZUuozIE/FGg== M;XB6TnnaJ4xGZUuozIE/FGg== Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 30 Jan 2014 06:20:42 -0000 On 1/22/14 3:41 PM, Ole Troan wrote: > I cannot claim credit for cooking up that dish. aren't you proposing > to do exactly that, replace periodic RAs with periodic RSs in: > draft-chakrabarti-nordmark-6man-efficient-nd Ole, The difference is between trying to replace periodic RAs by adding periodic RSs from all the hosts, but still needing the periodic RAs versus actually removing the need for periodic and muticast RAs. efficient-nd has the hosts tell the routers "I don't need a periodic RA" by the hosts including the ARO. Thus even on a potentially mixed link, the routers can be smart. But trying to accomplish the same thing without some additional information in the packets can't remove the periodic RAs as far as I can tell - it can only add load. >>> 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). >> You are speculating about some particular failure or misfeature in the network that makes it (persistently? sometimes?) drop multicast RAs. It would be good to flesh out that particular failure mode to see >> - whether it is realistic, and >> - what impact it has elsewhere. > it's relatively trivial to reproduce, but I suppose you can argue that setting timers that way is a misconfiguration. > 802.11 networks are multicast challenged, so I would expect drops to be somewhat common. > a more robust RS retransmit mechanism will help that somewhat. Occasional loss is handled by having the period RA timer be less than the default router lifetime (by 3x in the default values). Thus some RAs can be lost without any effect. If your multicast loss rate is higher than the config on the routers can change that ratio. Using unicast RSs could be more efficient (FWIW resilent-rs is about multicast RS - hard to know what proposal we are talking about when there isn't an actual complete proposal written up). But if the multicast period RAs have to be there to handle unmodified hosts you haven't gained much. >> For instance, the failure could be that all ICMP packets to the host are dropped (due to some misconfigured security policy - we've seen those in IPv4). That would drop unicast RAs as well, and affect the old path MTU discovery protocol. >> >> Or it could be that link-local multicast is misconfigured or broken, resulting in DNSSD and other protocols breaking. >> >> Having every host on the planet send a RS every 30 seconds "just in case" doesn't sound helpful. > true, although it wouldn't be 'just in case'. I think you are making a good argument that the current RS/RA mechanism is designed quite well. I'm merely arguing that it has a consistent design - worked well on yellow coax Ethernet. A different consistent and complete design might make sense for today's more multicast challenged networks. But I don't think that is just a tweak here and there - it would be a different design. I've been exploring this space for a while (starting in 6lowpan) and I'd be interested in working out a different design. There are ideas in efficient-nd, but that isn't complete. The frustrating thing is that the same folks that argue that the WG shouldn't work on a different design (targeting multicast challenged links), keep on suggesting tweaks. If the WG thinks we should work on improving ND for such links (and perhaps also improve it for battery operated hosts), then let's do that work. If not, then let's stop suggesting tweaks. Erik From nordmark@acm.org Wed Jan 29 22:22: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 C7F461A041A for ; Wed, 29 Jan 2014 22:22:56 -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 NuR2mgIcb1OJ for ; Wed, 29 Jan 2014 22:22:55 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id C37EE1A02F3 for ; Wed, 29 Jan 2014 22:22:55 -0800 (PST) Received: from [10.0.1.44] (184-23-158-201.dsl.dynamic.sonic.net [184.23.158.201]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s0U6MnWp003419 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 29 Jan 2014 22:22:49 -0800 Message-ID: <52E9EFB9.9000402@acm.org> Date: Wed, 29 Jan 2014 22:22:49 -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 , Ralph Droms 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;Ujgc8XaJ4xGTc+ozIE/FGg== M;8CRB8XaJ4xGTc+ozIE/FGg== Cc: draft-ietf-6man-resilient-rs@tools.ietf.org, IETF IPv6 Mailing 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: Thu, 30 Jan 2014 06:22:57 -0000 On 1/29/14 11:34 AM, Erik Kline wrote: >> A host on a multicast-capable link on which "unsolicited multicast Router Advertisements are never sent" will have to use the same transmission behavior as a host on a non-multicast-capable link, so that the host can learn of changes in the link prefixes in a timely fashion. > Not necessarily. > > Consider the situation in a which a router responds to multicast RSs > with unicast RAs. The host may in fact continue to receive unicast > RAs periodically. Erik, 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. Without clear details one can't say 1) whether this will work and 2) weather it would save any resources. Note (in case it isn't obvious) that a router can respond to a RS with a unicast RA - that is already allowed by 4861 and its predecessors. Erik From suresh.krishnan@ericsson.com Wed Jan 29 22:28: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 2CD3C1A04ED for ; Wed, 29 Jan 2014 22:28:00 -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 FbD3EB3nYAv7 for ; Wed, 29 Jan 2014 22:27:58 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id BC59D1A04E9 for ; Wed, 29 Jan 2014 22:27:58 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-36-52e9f0ec8060 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id A0.B0.11484.CE0F9E25; Thu, 30 Jan 2014 07:27:56 +0100 (CET) Received: from [164.48.125.57] (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.81) with Microsoft SMTP Server (TLS) id 14.2.347.0; Thu, 30 Jan 2014 01:27:54 -0500 Message-ID: <52E9F0E5.4020508@ericsson.com> Date: Thu, 30 Jan 2014 01:27:49 -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: IETF IPv6 Mailing List Subject: Summarizing discussion on draft-ietf-6man-resilient-rs 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+NgFnrMJMWRmVeSWpSXmKPExsUyuXRPoO6bDy+DDFZdkbJ4efY9kwOjx5Il P5kCGKO4bFJSczLLUov07RK4MqZOuMlY0MlRce/JGZYGxg1sXYycHBICJhIPH95lhrDFJC7c Ww8U5+IQEjjCKDFxxmQoZyujxJy9HawgVbwC2hLXz61nArFZBFQlNl7ZChZnA5q0YednsLio QJhE+4WZzBD1ghInZz5h6WLk4BAR0JK4u0cfJCwsYC/RfnkyI4jNLGArcWHOdRYIW15i+9s5 YK1CApoSW9d8Z4U4TlHixfGfTBMY+WchmToLSfssJO0LGJlXMXKUFqeW5aYbGW5iBAbUMQk2 xx2MCz5ZHmKU5mBREuf98tY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAMj45sf27fEd4Qm K5wTD2bZ8TlpzZ5X+/Z6zbn39eq5i28Zu5dNjstJeFa3RLrvdeyml5LzxLY8EV7vsubfiUrH E9PVeBtdnxyImzinsul7+OVmFt0ciXPrqm2UMtuyMmpyIs+KXTJKmvp70pzYkJqZAnH/fex5 Vq85c7Mt9+OplXdnsjK9X1thqcRSnJFoqMVcVJwIAFhLXtj2AQAA 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 06:28:00 -0000 Hi all, I would like to summarize the recent discussion on the resilient rs draft and ask for wg opinion on how to go forward with it. The discussion clearly showed that the draft does not handle the scenario laid out in Section 1 bullet b) on networks that have turned off periodic RA sending. [Note that scenario c) is still covered since the non-multicast capable links need to specify some form of periodic RS retransmission to elicit the RA]. There are two ways to resolve this inconsistency. One is to remove 1b) as a supported scenario. The other is to add support for periodic RS retransmission. The intention of the text in 1b) was to support links that do not send periodic (unsolicited) multicast RAs. As Erik Kline mentioned, they can still send periodic unicast RAs (i.e. Periodic non-initial RSs are not required). Is this a scenario we would like to support? It would be great to get the WGs opinion on this and we will submit a new revision based on what we hear. Thanks Suresh From ek@internetdraft.org Wed Jan 29 23:41: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 A92B51A04F8 for ; Wed, 29 Jan 2014 23:41:45 -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, 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 O56f_rSZaER7 for ; Wed, 29 Jan 2014 23:41:44 -0800 (PST) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.100]) by ietfa.amsl.com (Postfix) with ESMTP id 2D11D1A0476 for ; Wed, 29 Jan 2014 23:41:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zoho; d=internetdraft.org; h=content-type:mime-version:subject:from:in-reply-to:date:cc:message-id:references:to; b=c0HbtAV3AtZLcMth6nAu0gGbLxCvnH+Iw7RmP7bOD8Std2atP50GIShlymG3j2Sfm6gQC0ogzT0g eEziluchd0BFrf5jEO0zLMroZfxPBBH8g3xC5SwcCBeEYUqG30bbF8wnqV/sNtAhrRJoMsyko8PN PMwStROZeVwYbSFO5w4= Received: from [192.168.0.112] (c-69-181-65-10.hsd1.ca.comcast.net [69.181.65.10]) by mx.zohomail.com with SMTPS id 1391067686784897.7134095304955; Wed, 29 Jan 2014 23:41:26 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt From: Erik Kline In-Reply-To: <52E9EFB9.9000402@acm.org> Date: Wed, 29 Jan 2014 23:41:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131021233827.32495.34424.idtracker@ietfa.amsl.com> <6299FD64-01A9-4F19-B271-9891AFCA3269@gmail.com> <52E9EFB9.9000402@acm.org> To: Erik Nordmark X-Mailer: Apple Mail (2.1827) X-ZohoMailClient: External X-Zoho-Virus-Status: 2 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 07:41:45 -0000 On Jan 29, 2014, at 10:22 PM, Erik Nordmark wrote: > On 1/29/14 11:34 AM, Erik Kline wrote: >>> A host on a multicast-capable link on which "unsolicited multicast = Router Advertisements are never sent" will have to use the same = transmission behavior as a host on a non-multicast-capable link, so that = the host can learn of changes in the link prefixes in a timely fashion. >> Not necessarily. >>=20 >> Consider the situation in a which a router responds to multicast RSs >> with unicast RAs. The host may in fact continue to receive unicast >> RAs periodically. > Erik, >=20 > 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 =93until the router detects a NUD failure for the host=94 = notion, I think. In that case, I think the host will either: [1] enter into NUD detection from its perspective because = communications are failing (no replies to packets sent), or [2] it had to packets to send so didn=92t notice anything, and then = the RA timers get =93low=94 and the host enters into the proposed =93retry= RSes (probably requiring multicast)=94 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=92m not yet convinced it=92s terribly complicated. =85but maybe I just haven=92t thought about it enough. -Erik (the lesser)= From otroan@employees.org Thu Jan 30 02:23: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 DE6781A0448 for ; Thu, 30 Jan 2014 02:23:00 -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, 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 uV4gfLH39-pj for ; Thu, 30 Jan 2014 02:22:59 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 587741A042D for ; Thu, 30 Jan 2014 02:22:59 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAJkn6lKQ/khL/2dsb2JhbABZgwy+L4EFFnSCJQEBAQMBeQULC0ZXBogQCMtSF44aaAeDJIEUBJA+mgmDLjs X-IronPort-AV: E=Sophos;i="4.95,748,1384300800"; d="asc'?scan'208";a="4412110" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 30 Jan 2014 10:22:55 +0000 Received: from dhcp-lys02-vla252-10-147-116-99.cisco.com (dhcp-lys02-vla252-10-147-116-99.cisco.com [10.147.116.99]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0UAMr7a029052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 Jan 2014 10:22:54 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_82C8F099-5514-49C1-8539-E97860891E4F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Reducing the battery impact of ND From: Ole Troan In-Reply-To: <52E9EF2D.9050402@acm.org> Date: Thu, 30 Jan 2014 11:22:53 +0100 Message-Id: <2CFF305E-DE44-4D57-82D3-241196D94610@employees.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> To: Erik Nordmark X-Mailer: Apple Mail (2.1827) Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 30 Jan 2014 10:23:01 -0000 --Apple-Mail=_82C8F099-5514-49C1-8539-E97860891E4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Erik, > The frustrating thing is that the same folks that argue that the WG = shouldn't work on a different design (targeting multicast challenged = links), keep on suggesting tweaks. If the WG thinks we should work on = improving ND for such links (and perhaps also improve it for battery = operated hosts), then let's do that work. If not, then let's stop = suggesting tweaks. before designing anything new, I would like to see: - a clear description of the problem(s) - an analysis of how well we can do with existing protocols does that sound fair? cheers, Ole --Apple-Mail=_82C8F099-5514-49C1-8539-E97860891E4F 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 iQEcBAEBCgAGBQJS6if9AAoJEFuJXizso86gUTUH/1tZZpErqlinvXTCDTubhJ4z CvB6KoCqgMXdOGv1ToVkVPaW/CrR6exk7musjOe/3KlxlEH6UhRr0dOaKD7P3JPe BGdEjvvc8Mi+YuWxRpAjxlBmwkbpp6UwC+kcF3oj/kRqE89uhkDc1UomxavmL7Rs Stg6DyYUST7LFR78ZlzeWox4Q9X9CTYIKd0F553GDgrNAlRftcyW3YD1vilH5eHy GUxlc4GBJAKeAzRmmGjJH+R51UikNJlASHNRtTkzc+jx/+rYvJyV0Bhc5InD9S0f CAxHEmr0NgSlmdQZKCRQWZCujkTMc/2t0YCnh2eegx7567uMO5jcwX6KH0Rlm0Y= =Oq/B -----END PGP SIGNATURE----- --Apple-Mail=_82C8F099-5514-49C1-8539-E97860891E4F-- From warren@kumari.net Thu Jan 30 03:12: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 E6CE41A0485 for ; Thu, 30 Jan 2014 03:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 a_B5QWGfU6Fu for ; Thu, 30 Jan 2014 03:12:07 -0800 (PST) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 17B491A042C for ; Thu, 30 Jan 2014 03:12:06 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id y10so5962012wgg.10 for ; Thu, 30 Jan 2014 03:12:03 -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 :content-transfer-encoding; bh=lVka9uGS7igzsUHSie0JVnvoOtTGAGZtXrxl6A6PaWQ=; b=Q8S0j4Q6StUuKyk8+H/3CNNpbifXf2zn1zmTzBS03tCvN6Mq+xF1wcV7nTqei+5F+i I49w3qvDmToPwecueGZt3bJVEEfRWEP+hYl0J2mUotj4r151tCBhi44zvyKlpKkr9rdk 9/QJ2M+3fhWDUsXnD6umUYGheNVNpeKkIhwKuQuMOxQQhVn2Abt23iHssSGkLBay7iVo tWgt4jsCJgXYlDkf9nqpK/raduQzL/z2gpbAsKkGebnFH5hR/BEuwaXAMSjAcOTLVUS2 DnxiYdM/abNyrDN0Ybl+VBgPPT7QoFoxYivByqQHAFI29ZWzCN5y9xTnVtHgq4x5DwRU 2Ssg== X-Gm-Message-State: ALoCoQnfN3vSfPGU26MJarOR1/M40v2JII73eWNCljA74I6Ec0PQCGglMRDPDpLVV2OXXjEaSt0u MIME-Version: 1.0 X-Received: by 10.180.73.173 with SMTP id m13mr11440116wiv.52.1391080323279; Thu, 30 Jan 2014 03:12:03 -0800 (PST) Received: by 10.194.54.167 with HTTP; Thu, 30 Jan 2014 03:12:03 -0800 (PST) X-Originating-IP: [204.194.22.7] In-Reply-To: <2CFF305E-DE44-4D57-82D3-241196D94610@employees.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> Date: Thu, 30 Jan 2014 06:12:03 -0500 Message-ID: Subject: Re: Reducing the battery impact of ND From: Warren Kumari To: Ole Troan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Thu, 30 Jan 2014 11:12:10 -0000 On Thu, Jan 30, 2014 at 5:22 AM, Ole Troan wrote: > Erik, > >> The frustrating thing is that the same folks that argue that the WG shou= ldn't work on a different design (targeting multicast challenged links), ke= ep on suggesting tweaks. If the WG thinks we should work on improving ND fo= r such links (and perhaps also improve it for battery operated hosts), then= let's do that work. If not, then let's stop suggesting tweaks. > > before designing anything new, I would like to see: > - a clear description of the problem(s) > - an analysis of how well we can do with existing protocols > ... and can someone please remind me what exactly was wrong with ARP? Other than the fact that v4 uses it?! W > does that sound fair? > > cheers, > Ole > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From mawatari@jpix.ad.jp Thu Jan 30 05:21: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 9CA9B1A020C for ; Thu, 30 Jan 2014 05:21:30 -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 Tn5JLIIwG-KA for ; Thu, 30 Jan 2014 05:21:29 -0800 (PST) Received: from mail-gw.kbmail.jp (mail1185.kbmail.jp [106.187.230.185]) by ietfa.amsl.com (Postfix) with ESMTP id E72A41A01FC for ; Thu, 30 Jan 2014 05:21:28 -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 1C84011C0002 for ; Thu, 30 Jan 2014 22:21:24 +0900 (JST) Received: from ([202.90.12.5]) by bmlmta011.kbmail.jp id 52ea51d3000a41bb000062dc000063256800000f02e5; Thu, 30 Jan 2014 22:21:23 +0900 Date: Thu, 30 Jan 2014 22:21:23 +0900 From: MAWATARI Masataka To: ipv6@ietf.org Subject: Question about TEREDO prefix described in RFC 6890 Message-Id: <20140130222122.3484.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: Thu, 30 Jan 2014 13:21:30 -0000 Dear colleagues, I have been wondering about TEREDO Prefix (2001::/32). The following table on the RFC 6890 says that global of 2001::/32 is false. But actually 2001::/32 is on the global routing table now. If they reject anycasted 2001::/32 by ingress prefix filter, will TEREDO be workable? If I have any missing points, please let me know. --- http://tools.ietf.org/html/rfc6890#section-2.2.3 +----------------------+----------------+ | 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 --- Thanks in advance. Regards, Masataka MAWATARI From simon.perreault@viagenie.ca Thu Jan 30 06:21: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 993EB1A038C for ; Thu, 30 Jan 2014 06:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TtfwtwuBa-sG for ; Thu, 30 Jan 2014 06:21:20 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 22F601A037D for ; Thu, 30 Jan 2014 06:21:20 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id BF9DD40203 for ; Thu, 30 Jan 2014 09:21:16 -0500 (EST) Message-ID: <52EA5FDC.3090309@viagenie.ca> Date: Thu, 30 Jan 2014 09:21:16 -0500 From: Simon Perreault 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: Question about TEREDO prefix described in RFC 6890 References: <20140130222122.3484.8FE1F57E@jpix.ad.jp> In-Reply-To: <20140130222122.3484.8FE1F57E@jpix.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 14:21:21 -0000 Le 2014-01-30 08:21, MAWATARI Masataka a écrit : > The following table on the RFC 6890 says that global of 2001::/32 > is false. Looks to me like an errata in RFC 6890... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nordmark@acm.org Thu Jan 30 10:19: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 6ED3A1A0296 for ; Thu, 30 Jan 2014 10:19:44 -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 EjeWusTOV3ia for ; Thu, 30 Jan 2014 10:19:43 -0800 (PST) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id 219B61A0054 for ; Thu, 30 Jan 2014 10:19:43 -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 s0UIFVI4009544 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 30 Jan 2014 10:15:33 -0800 Message-ID: <52EA96C3.7040807@acm.org> Date: Thu, 30 Jan 2014 10:15: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: 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> In-Reply-To: <2CFF305E-DE44-4D57-82D3-241196D94610@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;4MolgdqJ4xGx+9RAJ1f4WQ== M;mJ1sgtqJ4xGx+9RAJ1f4WQ== 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: Thu, 30 Jan 2014 18:19:44 -0000 On 1/30/14 2:22 AM, Ole Troan wrote: > Erik, > >> The frustrating thing is that the same folks that argue that the WG shouldn't work on a different design (targeting multicast challenged links), keep on suggesting tweaks. If the WG thinks we should work on improving ND for such links (and perhaps also improve it for battery operated hosts), then let's do that work. If not, then let's stop suggesting tweaks. > before designing anything new, I would like to see: > - a clear description of the problem(s) > - an analysis of how well we can do with existing protocols > > does that sound fair? efficient-nd has that. If there are specific requests to clarify its description I'm all ears. But perhaps we should first determine whether the WG wants to work on something in this area, and whether efficient-nd is a reasonable starting point. So far I hear folks saying that we shouldn't work on this area, but at the same time providing suggestions (which have some issues as we've seen on the list) to improve things. So I'm confused. Erik From lorenzo@google.com Thu Jan 30 10:39: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 1378A1A0072 for ; Thu, 30 Jan 2014 10:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 bpyqqhvUKNMT for ; Thu, 30 Jan 2014 10:39:14 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0811A0292 for ; Thu, 30 Jan 2014 10:39:14 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id at1so3672166iec.11 for ; Thu, 30 Jan 2014 10:39:10 -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=g8dPkVpnZrqyJC4FXmaWg9N7hFAyOK0AvCt/l31EcB4=; b=YLe//pGLSZJq6/lmwnP7NX8wtdqGf2Dlcimp+ULmKPXeVFR68WTuqSm+W2MgcH9a3l rSfpiwfIedeyYQEy3WVQv9ZgDbdzJyUT6uMI3zZgjnvBhtXZ0o149gINw7MJF+ukV9FX TP9+/jlvCXfhQz0ENxxd3qOis4p9BlNrWs7+twnhrMlEUxnPgAMGl6/8qIcq3y6+dPlp fuCRTk+QAL20kxRzUhlirPHqsr99KGA5fcVDcvKB7qhTn83SYAPgbEKQ1eiR0FvxYAAZ +Q+badjcOpKmiytjagjLXEwQDy3H0fJJX6KgPYNKI2R2OmcinVWDrL9w7kzfQRGsghr5 4HZw== 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=g8dPkVpnZrqyJC4FXmaWg9N7hFAyOK0AvCt/l31EcB4=; b=ZEpmePg5YHAaAQJ9Or9bCjbMDk0MfrG0CXW+j5bfPnOh4Ig3kHYQSlFXtaOegNflWR a421e9ytvnUDJi/xcAtxAVXfzOB3DYJzfuc6E7ADyfzhxZ5DQ02oiQ2Zo/xBvRSqq2zt 3w0LVJtQc6VXi3/N7gH7JY+RRmBnoXas4PF/6eJfvgBT2sXmld3F7sph7Tz0RpgkBw0K QwfVSGnaPJpkJiiMgp7S9uCzX5WS9XmDa5fOcIvTbAVr66RSGd+fTR+JV16/ykpMcisb sxgQWpQeokPO+f2sWvG+/7rCb3JqCM1Z+Ere7rsf9ymj39+/O1ibiAVPAIHsc7G993A2 wTDQ== X-Gm-Message-State: ALoCoQkyTbzjEBGqKq3SB3IOgEhF9AYwhaxBe81KbOPVhdGCzSsEVH3ukmN1YzBVupcbyKDXIWEol3XHCBwn4QmaznvfzxJlT+00aSmWAjcp7egLF+8T2TPB87vqz04nZrCvGvqbdyDDAlU1cRs3FelX+f5SSueIow7rPqohAqKZh0v66b7K7Qsx0UxcXK9+j+Lzpf0dIPfl X-Received: by 10.42.246.131 with SMTP id ly3mr12093763icb.8.1391107150629; Thu, 30 Jan 2014 10:39:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Thu, 30 Jan 2014 10:38:50 -0800 (PST) In-Reply-To: <52E9EF2D.9050402@acm.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> From: Lorenzo Colitti Date: Thu, 30 Jan 2014 10:38:50 -0800 Message-ID: Subject: Re: Reducing the battery impact of ND To: Erik Nordmark Content-Type: multipart/alternative; boundary=90e6ba6e87108ef8ed04f1345fd2 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 30 Jan 2014 18:39:16 -0000 --90e6ba6e87108ef8ed04f1345fd2 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 29, 2014 at 10:20 PM, Erik Nordmark wrote: > The frustrating thing is that the same folks that argue that the WG > shouldn't work on a different design (targeting multicast challenged > links), keep on suggesting tweaks. If the WG thinks we should work on > improving ND for such links (and perhaps also improve it for battery > operated hosts), then let's do that work. If not, then let's stop > suggesting tweaks. > What tweaks are we talking about? The major change that's being suggested here is to increase the robustness of initial attach by changing "try three times and then give up" to "exponential backoff". I don't think anyone disagrees with that, right? As for unicast RAs, that's an operational issue. The specs allow it, and as Ole says, before going and changing the specs, we should hear (perhaps from v6ops?) that this is a real-world problem, and that changing the specs is the only or best way to fix that problem. --90e6ba6e87108ef8ed04f1345fd2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 29, 2014 at 10:20 PM, Erik Nordmark <nordmark@acm.org> wrote:
The frustrating thing is that the same folks that argue that the = WG shouldn't work on a different design (targeting multicast challenged= links), keep on suggesting tweaks. If the WG thinks we should work on impr= oving ND for such links (and perhaps also improve it for battery operated h= osts), then let's do that work. If not, then let's stop suggesting = tweaks.

What tweaks are we talking about? The majo= r change that's being suggested here is to increase the robustness of i= nitial attach by changing "try three times and then give up" to &= quot;exponential backoff". I don't think anyone disagrees with tha= t, right?

As for unicast RAs, that's an operational issue. Th= e specs allow it, and as Ole says, before going and changing the specs, we = should hear (perhaps from v6ops?) that this is a real-world problem, and th= at changing the specs is the only or best way to fix that problem.
--90e6ba6e87108ef8ed04f1345fd2-- From lorenzo@google.com Thu Jan 30 10:42: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 20EB81A044D for ; Thu, 30 Jan 2014 10:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 aqrUCDKGh6Lx for ; Thu, 30 Jan 2014 10:42:05 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8D21A0435 for ; Thu, 30 Jan 2014 10:42:05 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id ar20so3647473iec.20 for ; Thu, 30 Jan 2014 10:42:02 -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=bqEQP/uheFqshggN5QC9bwAYOG0DQ40QqXGcvwwIJmw=; b=D03h917bsLa99BeAil8lkL9T4bnvXhRFKFhIYNieQzJ1OyW3/PXpu4gOLpvj8pp6R0 fJ4I82ybsituSMn9dm7IsNzVKcArMhLGmn6kI0TEYyqDERKCfeb8Hx6wqK/tH1VL567y Q04Ft6+wjiDwlbG9kO4pqMRn31JTCPDqwXRzy7mSLG4wdmwwr23IPcFOmju/qN2JS3Dx shZ7r7RSx7sR2Arx2kEdYCm5OfSH3K915dMqnCwLVu1a/SQIwbE+zxuc9Ote7mz4/0kU iiSp8yS3YJBXVtApZfEPo+0HRUjs6Dqa43yjh99Pwhyk0kVQdgloqjggE2oAZkrnDBfn lt3Q== 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=bqEQP/uheFqshggN5QC9bwAYOG0DQ40QqXGcvwwIJmw=; b=jor2AMZa8IkX30VhGtM0dTJm7VJhPDWkhpl6NxG4iWAWKDU0pxQ89lbcubr3TN5cmE mhtkcLQnUxNaKypS3svZLcb2RBSENWqNnRYgTMubPYYOHK4CT0VQ1WcJ3OBRrHh5nilm ENE3jjn2QmoGR/735bZ04LMfXE0Z50V5NqcKCeSuUrGtFBLIIwIh6Wd8B5LW3g9gb/u2 aYpT5W8epvTeUvnuSLQOhWPMDux4AiNMk9ehWDgrMW49x3aeeM+vi4gFw9LTffIAy0oC r1qDIYh/4vALC2k+csQnEJlnCNo9vngLDojwawCwEvi8kJuNmjOUJMGhLy3cWxw9U3u2 Dq3w== X-Gm-Message-State: ALoCoQk+WHKoJb7bDH59f+HwIdIg1ssdAnhI+Eu2p6B52jNvqQxnKBdygTBCIrlQFfdsOqjwgvjH+/fgH2bOyeV+mXpLohktYfArkisAc0thRu64OOEd9883xmEULmq7SLptZhYG+iKM6wpxzICzC6mlhAq20k71fy7OMtCLvnVnUZIpV8y+NG3eTLRgsFBwoGxv9hwi1VTP X-Received: by 10.43.57.19 with SMTP id we19mr1168619icb.89.1391107322153; Thu, 30 Jan 2014 10:42:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Thu, 30 Jan 2014 10:41:40 -0800 (PST) In-Reply-To: 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> From: Lorenzo Colitti Date: Thu, 30 Jan 2014 10:41:40 -0800 Message-ID: Subject: Re: Reducing the battery impact of ND To: Warren Kumari Content-Type: multipart/alternative; boundary=bcaec51b2029c8388904f134690b 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: Thu, 30 Jan 2014 18:42:07 -0000 --bcaec51b2029c8388904f134690b Content-Type: text/plain; charset=UTF-8 On Thu, Jan 30, 2014 at 3:12 AM, Warren Kumari wrote: > ... and can someone please remind me what exactly was wrong with ARP? > Other than the fact that v4 uses it?! It's not energy-efficient. When anyone sends an ARP request, every node on the link has to wake up to process it, even though the packet is useful for only one node. Typically, ARP is also chattier than ND in terms of multicast/broadcast packets, because (in most implementations) it relies on timeouts rather than unreachability detection via unicast probes. --bcaec51b2029c8388904f134690b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 30, 2014 at 3:12 AM, Warren Kumari <warren@kumari.net> wrote:
... and can someone please remind me what e= xactly was wrong with ARP?
Other than the fact that v4 uses it?!

It= 9;s not energy-efficient. When anyone sends an ARP request, every node on t= he link has to wake up to process it, even though the packet is useful for = only one node. Typically, ARP is also chattier than ND in terms of multicas= t/broadcast packets, because (in most implementations) it relies on timeout= s rather than unreachability detection via unicast probes.
--bcaec51b2029c8388904f134690b-- From lorenzo@google.com Thu Jan 30 10:43: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 1C49B1A0451 for ; Thu, 30 Jan 2014 10:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 HAlIvMQ5ffvA for ; Thu, 30 Jan 2014 10:43:23 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id B1DE01A0072 for ; Thu, 30 Jan 2014 10:43:23 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id to1so3673280ieb.40 for ; Thu, 30 Jan 2014 10:43:20 -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=sF6Ft8iObUv8QZFQeMlw4aHGcNIzr8PM7qP0AqI0vuE=; b=jhoxr8Dh0FiTvcKDLgNFq2l/24SXLVJHRg9oSN9qO3KJ6BzCBF8q1GHB7X5OcAL96y UU7wjigQnkJfYXfNE1BiVwcx/elPFyD/JIeb9npSYyl0xxMw4e4daLBU92Dy7Lo3shw2 l8Dy4g/a/vEnAwTh147F/tC5Ldu7Go+XfxFL6UdDwXhVkJk06z8W/6UebcypMJ0Rv0+i vCXV73jTptkeUe53UDnfeIsNo5ftVwuAksbTl6/Reuzzcl4x03W74iAUDV2Yp/Cllpfn 2wLDX5wh8bqULmwYbwXLqjHzzbNYqLdv2Gsa/uWUMw9eVW9bmzCNWJsTXvg30xdpp5Cn 54yg== 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=sF6Ft8iObUv8QZFQeMlw4aHGcNIzr8PM7qP0AqI0vuE=; b=lRqqr9UsCmxjsk8f2KLE1yQ081mSOp1H4YviGWSbEinpSw2qKybJYIVGFB3BfLd45/ hdGoM8cpYovZx9tLZpRUwm2MhAPK7VsUzAFPHfKzM+J5j6ca3UV1ySvbbwoeKyyD2wUV RRuJQEA2O92B7gp84sFK/vUeC60e68FaqW7zkBE7Wgtpwmpt/eg7kxjetG+AJPa5oIIu NX6cVVT8esBXpLbk5LJSYc3pwIe4fLmPYaw+nLHIP/72MasLl2oTbFFIXy3ZZnJTg8gQ 6GHKAGHSiNFmY8+9mQYFd0nIlNEk6yCmaTfF8gTcgKtFg9sPCQyyWz8IPNoX82i2SRp0 aO2w== X-Gm-Message-State: ALoCoQmUwdszErjS6/XW0QDktHr/4Y0XiUCW9uwi7Quz8juTiTjG3cH6C8cRp/1pc6/at8UYbPbQ5zIVC5kYZtwKzXc6QtzJE7iBc+fTKiu9ym7mlapfLOvhU9suQsUxaxWMf05C50k9UPOoHNkcI2dMAXWe5elPiCKF1X89PLiQD6pKoHPHvHbY0AlTNOQJ86O27PUVyv1G X-Received: by 10.50.238.162 with SMTP id vl2mr15657386igc.45.1391107400235; Thu, 30 Jan 2014 10:43:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Thu, 30 Jan 2014 10:42:59 -0800 (PST) In-Reply-To: <52EA96C3.7040807@acm.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> <52EA96C3.7040807@acm.org> From: Lorenzo Colitti Date: Thu, 30 Jan 2014 10:42:59 -0800 Message-ID: Subject: Re: Reducing the battery impact of ND To: Erik Nordmark Content-Type: multipart/alternative; boundary=001a11335cfc6fb9d404f1346e82 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 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, 30 Jan 2014 18:43:25 -0000 --001a11335cfc6fb9d404f1346e82 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 30, 2014 at 10:15 AM, Erik Nordmark wrote: > So far I hear folks saying that we shouldn't work on this area, but at the > same time providing suggestions (which have some issues as we've seen on > the list) to improve things. > So I'm confused. Perhaps those folks are saying that they would like to see improvements in this area, as long as they can be made without major changes to the way the ND specs work. --001a11335cfc6fb9d404f1346e82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 30, 2014 at 10:15 AM, Erik Nordmark <nordmark@acm.org> wrote:
So far I hear folks saying that we shouldn't work on this area, but a= t the same time providing suggestions (which have some issues as we've = seen on the list) to improve things.
So I'm confused.

Perhaps those folks ar= e saying that they would like to see improvements in this area, as long as = they can be made without major changes to the way the ND specs work.=C2=A0<= /div>
--001a11335cfc6fb9d404f1346e82-- From brian.e.carpenter@gmail.com Thu Jan 30 11:45: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 099CC1A0450 for ; Thu, 30 Jan 2014 11:45: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 phhSgj6BY4OO for ; Thu, 30 Jan 2014 11:45:39 -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 AFFAE1A044E for ; Thu, 30 Jan 2014 11:45:39 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id kx10so3530763pab.35 for ; Thu, 30 Jan 2014 11:45: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=wmP0xkC9SXjn1BkTNtwAvjWkAva9sgaQ8PCMybDCaWk=; b=FVNOmINEe5QTBEMtL9yneq/sWRESDzlLd8auqpwUhEKljTVA6Geugk2/qmp2msjOeR elLUJDk7F5YLrH8fsg6zp5ml1JoL3kZ6MbgAcPXes0I+6dRZb6IdCh9kpMtpMR2ocg8J Om7/qRCLGTg5mr2XeaoPMHbbF43NC5Eso8X85PteSRei8e8JxNqMRQPH9SawFsxjFl2i yTEmI1um+2KhImdVtxrlf9+sQ3J/WZRr8zI0HUHtEIrMfsz0kNrrNc/G+k9Ds+M99lh+ YYWmw8kLHlqsmKFbRjV07rSYDr+5R3ebwKJXg7emvKDfuje1gVl3g9bPSeA3SrJG5Z5T kT5A== X-Received: by 10.66.154.169 with SMTP id vp9mr16061389pab.39.1391111136523; Thu, 30 Jan 2014 11:45:36 -0800 (PST) Received: from [192.168.178.23] (9.200.69.111.dynamic.snap.net.nz. [111.69.200.9]) by mx.google.com with ESMTPSA id mo2sm20158918pbc.6.2014.01.30.11.45.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Jan 2014 11:45:35 -0800 (PST) Message-ID: <52EAABE5.3060009@gmail.com> Date: Fri, 31 Jan 2014 08:45:41 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Simon Perreault Subject: Re: Question about TEREDO prefix described in RFC 6890 References: <20140130222122.3484.8FE1F57E@jpix.ad.jp> <52EA5FDC.3090309@viagenie.ca> In-Reply-To: <52EA5FDC.3090309@viagenie.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, 30 Jan 2014 19:45:41 -0000 On 31/01/2014 03:21, Simon Perreault wrote: > Le 2014-01-30 08:21, MAWATARI Masataka a =C3=A9crit : >> The following table on the RFC 6890 says that global of 2001::/32 >> is false. >=20 > Looks to me like an errata in RFC 6890... Agreed. The entry for 2002::/16 is better and that approach would work for 2001::/32, I think: N/A, see [RFC4380]. Both of these prefixes are routed as if they are global but they are special, so neither True nor False is correct. There is the same bug for fc00::/7, which is explicitly of global scope but special: N/A see [RFC4193]. Brian From iesg-secretary@ietf.org Thu Jan 30 15:54: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 B639A1A04DB; Thu, 30 Jan 2014 15:54:58 -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 RZKm6bjaAHtz; Thu, 30 Jan 2014 15:54:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 780791A0515; Thu, 30 Jan 2014 15:54:50 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Protocol Action: 'A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)' to Proposed Standard (draft-ietf-6man-stable-privacy-addresses-17.txt) X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140130235450.3929.82596.idtracker@ietfa.amsl.com> Date: Thu, 30 Jan 2014 15:54:50 -0800 Cc: 6man chair <6man-chairs@tools.ietf.org>, 6man mailing list , RFC Editor 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, 30 Jan 2014 23:54:59 -0000 The IESG has approved the following document: - 'A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)' (draft-ietf-6man-stable-privacy-addresses-17.txt) as Proposed Standard This document is the product of the IPv6 Maintenance Working Group. The IESG contact persons are Brian Haberman and Ted Lemon. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/ Technical Summary: This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware addresses (e.g., IEEE LAN MAC addresses), such that the benefits of stable addresses can be achieved without sacrificing the privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique- local addresses. Working Group Summary: This document was sent back to the working group based on the number of comments received during the IETF last call. The current document is significantly improved. After a long discussion, another working group last call was done with support from the w.g. The chairs had two reviewers, Ray Hunter and Mark Smith, did a detailed review of the draft. This resulted in several changes in the current draft (-14). The reviewers have told us that the new draft resolves the issues they raised. The w.g. chairs believe the draft is ready to send to the IESG again. In addition Alissa Cooper revised the document and is working on a draft that provides an overview of the privacy considerations with all types of IPv6 addresses. Document Quality: No implementations known. Personnel: Bob Hinden is the Document Shepherd. Brian Haberman is the Responsible Area Director. From fgont@si6networks.com Thu Jan 30 17:07: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 AB0871A0504 for ; Thu, 30 Jan 2014 17:07:43 -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 rIIUu8s-wQPR for ; Thu, 30 Jan 2014 17:07: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 E33FA1A04EE for <6man@ietf.org>; Thu, 30 Jan 2014 17:07:40 -0800 (PST) Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W92Zx-0002uU-J9; Fri, 31 Jan 2014 02:07:33 +0100 Message-ID: <52EAF63A.7050108@si6networks.com> Date: Thu, 30 Jan 2014 22:02:50 -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: "6man@ietf.org" <6man@ietf.org>, "Will Liu (Shucheng)" , "C. M. Heard" Subject: A problem with RFC 6465's Uniform Format for Extension Headers References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> In-Reply-To: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 X-Forwarded-Message-Id: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.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, 31 Jan 2014 01:07:43 -0000 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 From mawatari@jpix.ad.jp Thu Jan 30 17:24: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 6DF791A0515 for ; Thu, 30 Jan 2014 17:24:30 -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 totOrP-MyvTC for ; Thu, 30 Jan 2014 17:24:29 -0800 (PST) Received: from mail-gw.kbmail.jp (mail2052.kbmail.jp [106.187.231.52]) by ietfa.amsl.com (Postfix) with ESMTP id 98F841A0518 for ; Thu, 30 Jan 2014 17:24:25 -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 EF7DE6C0003 for ; Fri, 31 Jan 2014 10:24:20 +0900 (JST) Received: from ([202.90.12.1]) by bmlmta011.kbmail.jp id 52eafb440006e135000062dc000063256800000f14f5; Fri, 31 Jan 2014 10:24:20 +0900 Date: Fri, 31 Jan 2014 10:24:19 +0900 From: MAWATARI Masataka To: simon.perreault@viagenie.ca, brian.e.carpenter@gmail.com Subject: Re: Question about TEREDO prefix described in RFC 6890 In-Reply-To: <52EAABE5.3060009@gmail.com> References: <52EA5FDC.3090309@viagenie.ca> <52EAABE5.3060009@gmail.com> Message-Id: <20140131102419.46F9.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 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, 31 Jan 2014 01:24:30 -0000 Dear colleagues, Thank you very much. I didn't notice fc00::/7. Based on your comments I wrote a modified version as below. If anyone have any similar comments, I'd like to report that as an errata. Thanks in advance. +----------------------+----------------+ | 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 Kind Regards, Masataka MAWATARI * On Fri, 31 Jan 2014 08:45:41 +1300 * Brian E Carpenter wrote: > On 31/01/2014 03:21, Simon Perreault wrote: > > Le 2014-01-30 08:21, MAWATARI Masataka a ecrit : > >> The following table on the RFC 6890 says that global of 2001::/32 > >> is false. > > > > Looks to me like an errata in RFC 6890... > > Agreed. The entry for 2002::/16 is better and that approach > would work for 2001::/32, I think: N/A, see [RFC4380]. > > Both of these prefixes are routed as if they are global > but they are special, so neither True nor False is correct. > > There is the same bug for fc00::/7, which is explicitly > of global scope but special: N/A see [RFC4193]. > > Brian From ietfc@btconnect.com Fri Jan 31 02:04: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 4B1101A049B for ; Fri, 31 Jan 2014 02:04:27 -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] 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 tl9ZXY-BUjDR for ; Fri, 31 Jan 2014 02:04:25 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 28B801A0476 for ; Fri, 31 Jan 2014 02:04:24 -0800 (PST) Received: from mail21-va3-R.bigfish.com (10.7.14.230) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 31 Jan 2014 10:04:21 +0000 Received: from mail21-va3 (localhost [127.0.0.1]) by mail21-va3-R.bigfish.com (Postfix) with ESMTP id 3C13EE0229; Fri, 31 Jan 2014 10:04:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -14 X-BigFish: PS-14(zz9371I542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h20f7h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh19f0h1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h2218h2216h226dh22d0h24afh2327h2336h2438h2461h2487h24d7h2516h304l1d11m1155h) Received: from mail21-va3 (localhost.localdomain [127.0.0.1]) by mail21-va3 (MessageSwitch) id 1391162659459964_8247; Fri, 31 Jan 2014 10:04:19 +0000 (UTC) Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.241]) by mail21-va3.bigfish.com (Postfix) with ESMTP id 584A12A0046; Fri, 31 Jan 2014 10:04:19 +0000 (UTC) Received: from DB3PRD0710HT003.eurprd07.prod.outlook.com (157.56.253.85) by VA3EHSMHS023.bigfish.com (10.7.99.33) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 31 Jan 2014 10:04:12 +0000 Received: from pc6 (81.159.188.189) by pod51017.outlook.com (10.255.75.38) with Microsoft SMTP Server (TLS) id 14.16.411.0; Fri, 31 Jan 2014 10:04:01 +0000 Message-ID: <00d101cf1e6b$253380e0$4001a8c0@gateway.2wire.net> From: t.petch To: Fernando Gont References: <20140130235450.3929.82596.idtracker@ietfa.amsl.com> Subject: Re: Protocol Action: 'A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)' to Proposed Standard (draft-ietf-6man-stable-privacy-addresses-17.txt) Date: Fri, 31 Jan 2014 09:59:27 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.159.188.189] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: 6man mailing 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: Fri, 31 Jan 2014 10:04:27 -0000 Fernando Congratulations. When I first saw this I-D, I thought what a sensible idea. Since then, I have been surprised, amazed even, at the opposition that has been put up, on this list, on the IETF list and even by the IESG. I have wondered why and have no rational explanation but do believe that you deserve a special mention for seeing this through, when others might have given up long ago (well, I would have done:-( So, congratulations. Tom Petch ----- Original Message ----- From: "The IESG" To: "IETF-Announce" Cc: "6man chair" <6man-chairs@tools.ietf.org>; "6man mailing list" ; "RFC Editor" Sent: Thursday, January 30, 2014 11:54 PM Subject: Protocol Action: 'A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)' to Proposed Standard (draft-ietf-6man-stable-privacy-addresses-17.txt) > The IESG has approved the following document: > - 'A Method for Generating Semantically Opaque Interface Identifiers with > IPv6 Stateless Address Autoconfiguration (SLAAC)' > (draft-ietf-6man-stable-privacy-addresses-17.txt) as Proposed Standard > > This document is the product of the IPv6 Maintenance Working Group. > > The IESG contact persons are Brian Haberman and Ted Lemon. > > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses / > > > > > Technical Summary: > > This document specifies a method for generating IPv6 Interface > Identifiers to be used with IPv6 Stateless Address Autoconfiguration > (SLAAC), such that addresses configured using this method are stable > within each subnet, but the Interface Identifier changes when hosts > move from one network to another. This method is meant to be an > alternative to generating Interface Identifiers based on hardware > addresses (e.g., IEEE LAN MAC addresses), such that the benefits of > stable addresses can be achieved without sacrificing the privacy of > users. The method specified in this document applies to all prefixes > a host may be employing, including link-local, global, and unique- > local addresses. > > Working Group Summary: > > This document was sent back to the working group based on the number of > comments received during the IETF last call. The current document is > significantly improved. After a long discussion, another working > group last call was done with support from the w.g. The chairs had two > reviewers, Ray Hunter and Mark Smith, did a detailed review of the > draft. This resulted in several changes in the current draft (-14). > The reviewers have told us that the new draft resolves the issues they > raised. The w.g. chairs believe the draft is ready to send to the IESG > again. > > In addition Alissa Cooper revised the document and is working on a draft > that provides an overview of the privacy considerations with all types of > IPv6 addresses. > > Document Quality: > > No implementations known. > > Personnel: > > Bob Hinden is the Document Shepherd. > > Brian Haberman is the Responsible Area Director. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From otroan@employees.org Fri Jan 31 08:13: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 1A8951A041A for ; Fri, 31 Jan 2014 08:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 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] 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 2FGabSi1_SLv for ; Fri, 31 Jan 2014 08:13:53 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 163D91A03C2 for ; Fri, 31 Jan 2014 08:13:53 -0800 (PST) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id C56116086; Fri, 31 Jan 2014 08:13:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :content-type:subject:date:message-id:cc:to:mime-version; s= selector1; bh=Cx4yrJYQdB9aX3bUXjRmlr5xQS8=; b=OvMObKtvkLrx70cD90 o9LVabWwJhTHeLNkVeEXA0S4w8lFoN8mJAQGLBDaRsRxgPYHuAYsj+Wpv9OuciNn n8B375l6ziBvFzxF5Gm1gyX511lkkkmZsRq6njJSn9R5v08VDI+bVrwTd4pi1Dh4 5aWjs/nCW7x9BM7b75Of0WJGg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :content-type:subject:date:message-id:cc:to:mime-version; q=dns; s=selector1; b=eSqkKl23n5O5tpUAgTT4ce8gafcb5RDq1oTKR8vReTymhRdc ARLppOPd2AKWcSvAb02G0+xEBBL+u1Fiz8Oou6GK5FJ1T/qM5ZK4u3KIJ44Bh43Q 7axMwzuyAbIQJVM2hNSm3qIYUX+QM0kyDAfcOEzwwLSjveecmhnI1RGxCn0= Received: from dhcp-10-61-99-155.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 77D0E604C; Fri, 31 Jan 2014 08:13:46 -0800 (PST) From: Ole Troan Content-Type: multipart/signed; boundary="Apple-Mail=_3E5AAA57-1AC3-4F77-906E-9EA676EA9E6E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: 6man IETF 89 Call for agenda items Date: Fri, 31 Jan 2014 17:13:44 +0100 Message-Id: <07799DB5-2CAD-4CE9-96D9-EA584F3B3683@employees.org> To: 6man WG Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) 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: Fri, 31 Jan 2014 16:13:55 -0000 --Apple-Mail=_3E5AAA57-1AC3-4F77-906E-9EA676EA9E6E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii --- We have asked for a two and a half hour slot in London for the 6MAN = working group. If you have a draft you would like to discuss, please send your request = for agenda time to the 6man chairs. Please include in the request, the title and file name of the draft, the = speakers name (and email), and how much time you need. We will prioritise drafts that are working group items and drafts that = have been actively discussed on the list. We expect about half the presentation time to be used for open = discussion, please plan your presentation accordingly. New drafts not discussed on the mailing list prior to the meeting, or drafts that do not appear to have support from the working group are = unlikely to get time at the meeting. Please have agenda items to us by 2014-02-17 and also note the draft = deadline for IETF89: 2014-02-14 (Friday): Internet Draft submission cut-off (for all drafts, = including -00) by UTC 24:00 Regards, Bob & Ole --Apple-Mail=_3E5AAA57-1AC3-4F77-906E-9EA676EA9E6E 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 iQEcBAEBCgAGBQJS68u4AAoJEFuJXizso86gabgIAI2jb6FhfGSv44ohZu8f/xs2 e9rzL2iDkhd49rPIGKj1nRB8qiPLm4vz/jvw8DOuE+d8wpexhSXpqhCbxQlx/59M e8Anskq/VQl9MbZdn7h1zHfpeAw7qOcRDJjIVl6a3YcpceLoukG2cJHVzsnWr65o Lliycr2yirnuViMw9VBHY5IJgjr6g7Y1c6vluMfIsYoekJxBHHJJAyAeNMMjb4+s M0ItYHmgd4gEDVx4tz11mOdHKJ2AKTIGd9heXIJuvNbl+2hv/3YrVjLL6Up+dw94 78k5jSsAg8EefcAMfMMnzDydRkdgs547s80Ah4noOWdqwGji1Q6Q4R5BVckZAxQ= =/mcu -----END PGP SIGNATURE----- --Apple-Mail=_3E5AAA57-1AC3-4F77-906E-9EA676EA9E6E-- From nordmark@acm.org Fri Jan 31 23:50: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 4B17F1A0542 for ; Fri, 31 Jan 2014 23:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.166 X-Spam-Level: X-Spam-Status: No, score=0.166 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 zQjqH38fMn9b for ; Fri, 31 Jan 2014 23:49:59 -0800 (PST) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id 311CE1A0534 for ; Fri, 31 Jan 2014 23:49:59 -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 s117nqqm015283 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 31 Jan 2014 23:49:52 -0800 Message-ID: <52ECA722.60501@acm.org> Date: Fri, 31 Jan 2014 23:49:54 -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: IETF IPv6 Subject: Fwd: Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt References: <52EA9628.4020700@sonic.net> In-Reply-To: <52EA9628.4020700@sonic.net> X-Forwarded-Message-Id: <52EA9628.4020700@sonic.net> Content-Type: multipart/alternative; boundary="------------060404020103050905010901" X-Sonic-ID: C;LOMobxWL4xGUPEOPJ1f4WQ== M;VFpNbxWL4xGUPEOPJ1f4WQ== 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 07:50:02 -0000 This is a multi-part message in MIME format. --------------060404020103050905010901 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit [Retransmit - I don't think this made it to the list] -------- Original Message -------- Subject: Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt Date: Thu, 30 Jan 2014 10:12:56 -0800 From: Erik Nordmark To: Erik Kline , Erik Nordmark CC: Ralph Droms , draft-ietf-6man-resilient-rs@tools.ietf.org, IETF IPv6 Mailing List 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) > --------------060404020103050905010901 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
[Retransmit - I don't think this made it to the list]

-------- Original Message --------
Subject: Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt
Date: Thu, 30 Jan 2014 10:12:56 -0800
From: Erik Nordmark <nordmark@sonic.net>
To: Erik Kline <ek@internetdraft.org>, Erik Nordmark <nordmark@acm.org>
CC: Ralph Droms <rdroms.ietf@gmail.com>, draft-ietf-6man-resilient-rs@tools.ietf.org, IETF IPv6 Mailing List <ipv6@ietf.org> 


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)
>


--------------060404020103050905010901-- From nordmark@acm.org Fri Jan 31 23:50: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 D653C1A1F71 for ; Fri, 31 Jan 2014 23:50:30 -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 OnQzD0RkaeL0 for ; Fri, 31 Jan 2014 23:50:29 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7051D1A1F56 for ; Fri, 31 Jan 2014 23:50:29 -0800 (PST) Received: from [10.0.1.44] (184-23-158-201.dsl.dynamic.sonic.net [184.23.158.201]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s117n0qp012438 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 31 Jan 2014 23:49:00 -0800 Message-ID: <52ECA6EE.1080201@acm.org> Date: Fri, 31 Jan 2014 23:49:02 -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: Warren Kumari , Ole Troan 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;EqMGUBWL4xGBRQhpIE/FGg== M;8oovUBWL4xGBRQhpIE/FGg== 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: Sat, 01 Feb 2014 07:50:32 -0000 On 1/30/14 3:12 AM, Warren Kumari wrote: > ... and can someone please remind me what exactly was wrong with ARP? > Other than the fact that v4 uses it?! Warren, Are you asking about the specifics of this topic (how to save on battery and 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 addresses per interface, and a way to renumber those addresses. The nascent DHCPv4 wasn't architected to support multiple addresses. We had RFC 1256 (ICMP router discovery) as a protocol with very limited deployment for one of the above pieces. We wanted a more extensible packet format than ARP and reusing IP/ICMP seemed 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 - but the more extensible packet format was key.) For the more general question of battery and multicast/broadcast, folks seem to agree that current ND (with address resolution spread across a large number of multicast addresses) is more scalable than ARP's broadcast. (But on WiFI where broad/multicast is lower bandwidth and less reliable they have the same issue.) Erik > > W > > >> does that sound fair? >> >> cheers, >> Ole >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>