From nobody Thu Feb 1 15:15:55 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4635912F2A6 for ; Thu, 1 Feb 2018 15:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 u_kC5CwvMNXh for ; Thu, 1 Feb 2018 15:15:51 -0800 (PST) Received: from g4t3427.houston.hpe.com (g4t3427.houston.hpe.com [15.241.140.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADC3C12F28B for ; Thu, 1 Feb 2018 15:15:51 -0800 (PST) Received: from G9W8455.americas.hpqcorp.net (exchangepmrr1.us.hpecorp.net [16.216.161.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g4t3427.houston.hpe.com (Postfix) with ESMTPS id E8C4157 for ; Thu, 1 Feb 2018 23:15:50 +0000 (UTC) Received: from G2W6309.americas.hpqcorp.net (2002:10c5:4033::10c5:4033) by G9W8455.americas.hpqcorp.net (2002:10d8:a15e::10d8:a15e) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 1 Feb 2018 23:15:50 +0000 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (15.241.52.13) by G2W6309.americas.hpqcorp.net (16.197.64.51) with Microsoft SMTP Server (TLS) id 15.0.1178.4 via Frontend Transport; Thu, 1 Feb 2018 23:15:50 +0000 Received: from CS1PR8401MB0664.NAMPRD84.PROD.OUTLOOK.COM (10.169.15.9) by CS1PR8401MB0998.NAMPRD84.PROD.OUTLOOK.COM (10.169.96.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.14; Thu, 1 Feb 2018 23:15:48 +0000 Received: from CS1PR8401MB0664.NAMPRD84.PROD.OUTLOOK.COM ([fe80::fc72:4b21:9b70:c41f]) by CS1PR8401MB0664.NAMPRD84.PROD.OUTLOOK.COM ([fe80::fc72:4b21:9b70:c41f%18]) with mapi id 15.20.0444.021; Thu, 1 Feb 2018 23:15:48 +0000 From: "Bottorff, Paul" To: "int-area@ietf.org" Thread-Topic: GUE Support Thread-Index: AQHTm7JOY/beITymsU258f0n7D9Khg== Date: Thu, 1 Feb 2018 23:15:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=paul.bottorff@hpe.com; x-originating-ip: [15.203.233.81] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CS1PR8401MB0998; 7:XE1KhwkFnoPbCE7dCzG9heL+EpJOM8QHZ5uhdX85yvssIjRBITvReEMLiF5GaUtQdWnuv/KqlUNsYxCqh7ZP87WFt4mvuR76GQ8SuvnplK1A2B0dB4xHe+GjlN53pufgMM29O92DeZ3lVbGpbznLfwsvdr3LKH8Fz3S336owEC5MJQKSFKn7pIZ7ZUgWpdXYnmlAAyykdNV4ei1nvqgdRpcHRaAk9IRz1UH5cORywFavFnwdcUekudzIXv00AtRV x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6ca898f7-e95e-49f5-4213-08d569c9bb01 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989060)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:CS1PR8401MB0998; x-ms-traffictypediagnostic: CS1PR8401MB0998: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(156600954879566)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231101)(2400082)(944501161)(93006095)(93001095)(6055026)(6041288)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CS1PR8401MB0998; BCL:0; PCL:0; RULEID:; SRVR:CS1PR8401MB0998; x-forefront-prvs: 0570F1F193 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(39380400002)(39860400002)(346002)(396003)(189003)(199004)(105586002)(102836004)(3480700004)(6916009)(221733001)(186003)(5250100002)(26005)(66066001)(2900100001)(33656002)(3846002)(68736007)(2351001)(6116002)(74316002)(86362001)(106356001)(7736002)(2501003)(6506007)(2906002)(8936002)(7116003)(5660300001)(8676002)(81156014)(81166006)(6306002)(55016002)(558084003)(478600001)(25786009)(236005)(606006)(7696005)(54896002)(9686003)(316002)(3660700001)(99286004)(6436002)(5640700003)(97736004)(14454004)(53936002)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:CS1PR8401MB0998; H:CS1PR8401MB0664.NAMPRD84.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: hpe.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: zE6zfYy2yPGF7BwVLfcjCmYwTH9EE/6IkVJzjg5U7v+Q3BYqnIwie4q8ZunVE9veKA3tUfVQp3pjquaNkTaUog== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CS1PR8401MB0664FAA054CCADAF9558CFF2FEFA0CS1PR8401MB0664_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6ca898f7-e95e-49f5-4213-08d569c9bb01 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2018 23:15:48.8776 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: CS1PR8401MB0998 X-OriginatorOrg: hpe.com Archived-At: Subject: [Int-area] GUE Support X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 23:15:53 -0000 --_000_CS1PR8401MB0664FAA054CCADAF9558CFF2FEFA0CS1PR8401MB0664_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support standardizing GUE. Paul Bottorff Sent from Mail for Window= s 10 --_000_CS1PR8401MB0664FAA054CCADAF9558CFF2FEFA0CS1PR8401MB0664_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support standardizing GUE.

 

Paul Bottorff

 

Sent from Mail for Windows 10

 

--_000_CS1PR8401MB0664FAA054CCADAF9558CFF2FEFA0CS1PR8401MB0664_-- From nobody Thu Feb 1 20:32:35 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F81C12EA91; Thu, 1 Feb 2018 20:32:33 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WF35FYnonPl8; Thu, 1 Feb 2018 20:32:31 -0800 (PST) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52624127337; Thu, 1 Feb 2018 20:32:28 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id c78so12260025ywb.13; Thu, 01 Feb 2018 20:32:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=qNnB31R80O35GPlAQtNMHzTKUw+nQTmByGEHChhja9g=; b=dac37rP6hO9ftL6begHocwdnnwIz4b5lYdOqWH+H9NBwxXppVwk1IAa5gTxKIcJTY5 mEL8ZDh5/OiEvfgfpqT1TRC9ACjak5KToGhXie0CFJAm9+a4nQXpU8E7XYizREDQc3Kj CcIveTJUk/nao/qPsnKWtDOIZHGQxrRZYM6qt1jaJXGdwR++yckDRhFmxOh10WORuuqY n4qyWlGuzemQEsrzlRUZF0PFz+2Ku5t6eCCmka5Q6WnoWOrDIIeyyuNSCvmyduCFJM6T bWjbM8tYSZv/KiC3jCcc5E/KDSpRepnWTs8SwqoteqEGa81WCW/QQC7Ouf3RziOEvx7v HXRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=qNnB31R80O35GPlAQtNMHzTKUw+nQTmByGEHChhja9g=; b=OlJBzgNet5sCvCRVrEMJSmJqFDAi1XXEHtBBzRnk2xynKeUXFAiw9kIMn5cnoem+F6 aGgUqjA5RnGpVXSqDcVz4vv+QYHExcnvrWb3YjeWhw8KAa2LjqPQWDv0Ho0SgYwJ/51y 52voMNIcHh2kJ9YVgKfU/PZzII/hPF6ZaYe4aorUaSon1yplPIMbNIVBvlVo9pLz3aWK /cNW4snemcHKGH0/myqWMRlzi8wNm04SOJj7tqgSWri5F1hAbllA0XDVtQcL46JjAHOY SzhSBRhoUWL3G+vEpZfGZRghEGtX2RfJoyykw/krtwLVXBvfpT9BktFkcFaPEIVNkFnL 7maA== X-Gm-Message-State: AKwxyte2EQobwyS1aMT2uutSc2wnPdm2t7HHhuDdfOnxosUi64v7lcN9 wYIJcoKA0nGJSL8CuOpGlGZOV+5g X-Google-Smtp-Source: AH8x227v+78nBxYr1J0RXti07Emoin2yUGjIGawTWpeJvLSmyprvLC3cFNiCNzVno7UShdOAoa0GIg== X-Received: by 10.37.136.141 with SMTP id d13mr19147541ybl.446.1517545946997; Thu, 01 Feb 2018 20:32:26 -0800 (PST) Received: from [10.0.0.10] (45-19-110-76.lightspeed.tukrga.sbcglobal.net. [45.19.110.76]) by smtp.gmail.com with ESMTPSA id k185sm479949ywf.81.2018.02.01.20.32.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Feb 2018 20:32:26 -0800 (PST) From: Suresh Krishnan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <92D139B9-D140-4B14-A212-01FCB578BCBD@gmail.com> Date: Thu, 1 Feb 2018 23:32:25 -0500 Cc: draft-ietf-intarea-probe.all@ietf.org To: int-area X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [Int-area] RFC Editor Note for draft-ietf-intarea-probe-10 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 04:32:33 -0000 Hi all, The IANA evaluation of this document and the resulting codepoint = allocation pointed out a potential misunderstanding regarding the = desired range of code points (Thanks Amanda and Ron for sorting this = out!). It would be nice to fix the IANA considerations text in the = document to clarify this for posterity. I would like to take care of = this with an RFC Editor Note instead of doing this during AUTH48. Please = let me know if you have any comments or concerns regarding this. Thanks Suresh OLD: Add an entry to the "ICMPv6 "type" Numbers" registry, representing the = Extended Echo Reply. This entry has the following codes: (0) No Error, = (1) Malformed Query, (2) No Such Interface, (3) No Such Table Entry, (4) = Multiple Interfaces Satisfy Query. NEW: Add an entry to the "ICMPv6 "type" Numbers" registry, representing the = Extended Echo Reply. This entry has the following codes: (0) No Error, = (1) Malformed Query, (2) No Such Interface, (3) No Such Table Entry, (4) = Multiple Interfaces Satisfy Query. As ICMPv6 distinguishes between = informational and error messages, and this is an informational message, = the value must be assigned from the range 128-255. From nobody Sat Feb 3 11:24:34 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0314127871; Sat, 3 Feb 2018 11:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.729 X-Spam-Level: X-Spam-Status: No, score=-2.729 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LW6YaO15X-3E; Sat, 3 Feb 2018 11:24:30 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9436A12DA06; Sat, 3 Feb 2018 11:24:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1517685870; bh=+dQUkqCDzCy/RtTatdWKJCtiTb0kkUAYV3hd SPaX9+0=; h=Received:Subject:To:References:Cc:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: X-ELNK-Trace:X-Originating-IP; b=NgeOsOByHw0mARZ8g1S/++PjaVJ8+npkc fckdtNK6Fx7fncK+TzChuOBGsk490kop3dgKT5vatmz4FFp+lMPbkf9ozViBixGW97Q spSxL22Z3iQ1BlYreJzEBcj95GevKjZRwz5PSmX/BskpYhJZ20DjOU50pSHLikkUpzb mGKIm2mphBWAYwYhVq/BAmTTWBKRUgnTHHM5hmulC1GA8ZzqpKFzfvkGmR0g9fLsZ9I BGocVxRcnikA0aZuEj6U1TO+eQ8PSI1kFRnpgCxvx97VoFy4CiP2TIQLq50BLEot9wR V3R7oaR7Niy1SUPBirFrJM4L+oX7W+W1/EpIvEseg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=Gl3dGRctzSVe1AEw/OcBicjq/1hxTY1nTnaTUChqE9xJUwPBOYd0sgh7ncP2k8t+AwfM1ZRRwdBu6xuWD/nLwUNKmfz1G/5xpvP2Dbpy7CbJHGINNxo6401uPLkHxxGzQXqb41NAUjeVH3Th50czBZv847TPkBv3zbXp2PnBDS+Jolhw5WQId9vHOFhpVFeQg/1/uFeWW6hGot3jrhMpRbfXk9oeTvlXxsrkioU9iBe5k7Ybr1m6IByC0Ib/5ySKXr+j27vq0MarZ4623A/QOiW2UCNRHmu5BV+x/ucpdTa91S9KvIT2rVzrapt+JsxzOMQZ7c6QDVuC04dBpp1MnQ==; h=Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from ) id 1ei3QH-000B2X-43; Sat, 03 Feb 2018 14:24:25 -0500 To: joel jaeggli , "mboned@ietf.org" References: <8140d9e4-b322-7f39-a37c-a96ab7283ffe@bogus.com> Cc: Internet Area , draft-ietf-mboned-ieee802-mcast-problems@ietf.org From: Charlie Perkins Message-ID: <55569b5a-cf0b-ea3d-2464-eff1ec62450c@earthlink.net> Date: Sat, 3 Feb 2018 11:24:22 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <8140d9e4-b322-7f39-a37c-a96ab7283ffe@bogus.com> Content-Type: multipart/alternative; boundary="------------7F827E5419E36E0DBA231F2A" Content-Language: en-US X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956846b590522b13c9503957d57459a85a5041c60fdc0ba6785350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: Re: [Int-area] review of draft-perkins-intarea-multicast-ieee802-03 draft-mcbride-mboned-wifi-mcast-problem-statement-01 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 19:24:34 -0000 This is a multi-part message in MIME format. --------------7F827E5419E36E0DBA231F2A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Joel, The [mboned] WG has adopted draft-ietf-mboned-ieee802-mcast-problems.  I have just posted an update that includes the relevant material from the earlier [intarea] individual submission, draft-perkins-intarea-multicast-ieee802, which you also reviewed. I have some follow-up to your review comments below. On 11/14/2017 6:36 PM, joel jaeggli wrote: > Greetings, > > I have chosen to review both of these documents at this time as they > appear to me to be attempts to address the same problem space from the > vantage point of slightly different but overlapping communities > (evidenced by the authors) both of which have a vested interest in IP > multicast operation on ieee 802.xx wireless networks. This review is > seperated into the observations common to both followed by (limited) > commentary on each document. > > While both documents address the challenges of arp / ND and aperiodic > multicast transmission, > draft-mcbride-mboned-wifi-mcast-problem-statement-01 has more focus on > application use of multicast above and beyond basic > subnet/adjacency/resource discovery applications. > > draft-perkins-intarea-multicast-ieee802-03 takes a more technical and > nuanced look at the underlying 802.xx implementation of > multicast/broadcast packet transmission. It is oddly specific in some > areas to experiences gleaned from the IETF network, which while it may > be a product of our experience, is by no means a unique environment, > and these challenges are to a great degree common or in fact worse in > other wireless environments (where there might be more low powered > devices, less spectrum or radio coordination, a diversity of management > domains and so on. The contents of that draft were pretty much contributed text from the co-authors, and there were a number of empty holes for future work.  But the future work kept not getting done. > > it's not clear to me from the outset what the audience for an > eventually published document might be. > > Advice to implementors? Yes. > > Feedback to the IEEE? Not specifically, but the IEEE folks would definitely notice any work that we do. > > Operational advice? Yes. > > Go from problem statment towards work on conclusions? I am not sure about this.  For now I would put it as a lower priority, except insofar as bits of advice to implementers and operators would count as conclusions. > > draft-perkins-intarea-multicast-ieee802-03 is the slightly more mature > document of the two, I don't think that there is much justification for > advancing both given that they have fairly high overlap without being > complimentary, so I would encourage consolidation and coordination > between the int interests and those of the mbone/multicast community > towards something that is more than the union of the two. Check. > > >From my vantage-point the best outcome is one where the IETF provides > advice to vendors (becaue there are implementation specific tweaks and > optimation that can make many situations better) an the IEEE that > results in the employment of multicast being less disruptive and costly > and potentially to devices on wireless lans. work on ietf protocols > associated with arp/nd resource discovery to make them generally less > costly on the wire and more sensitive to power / cpu usage is a > desirable property as well pariticularly of there are situations where > they can be avoided entirely (for example not having to defend addresses > via DAD because of something like > https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-13). I very much agree with this. > > > Some comments specific to each document > > - draft-perkins-intarea-multicast-ieee802-03 - > > 3.1.2. Lower Data Rate > > this rate might be as low as 6 Mbps, when > some unicast links in the same cell can be operating at rates up to > 600 Mbps. > > In fact backward compatibility and multi-stream implementations mean > that the maximum unicast rates are currently up to a few Gb/s so there > can be a more than 3 order of magnitude difference in the transmission > rate from the basic rates to optimal unicast forwarding. some techinues > employed to increase spectral efficiency such a spatial multiplexing in > mimo systems are literally unavailable with more then one intended > reciever so it's not simply the case that nominal transmission rates > available are limited by backwards compatibility. We could incorporate a version of your text into section 3.1.2 of the new revision. > 3.2.2. IPv6 issues > > Respecting some of the cost of multicast on wireless networks these are > not strictly wireless problems reductions in the amount of signaling > required is better for the control-planes of routers, and for all hosts > ultimately, whether that is unicast RAs, prefix per host, or simply rate > limits on layer 2 learning e.g. https://tools.ietf.org/html/rfc6583 > problems. 3.2.4 and 3.2.2 therefore are very much problems that extend > beyond the wireless domain. > > Specifically with 3.2.4 the arp problem also applies to ND, in both > cases non-standard counter-measures (arp sponging unlearned entries as > in 5.1 for v4) various forms of off-net vs on-net driven ND suppression. Do you think that the draft should avoid mention of problems that are not specific only to multicast, or should we mention them anyway along with the observation that they also extend beyond the wireless domain? > > On a wired network, there is not a huge difference amongst unicast, > multicast and broadcast traffic; > > Inadvertent flooded traffic or high amounts of ethernet multicast on > wired networks can be quite a bit less costly due to nic filtering, then > in cases where devices have to wake up effectively to process packets. > also the fact that these networks tend to be switched futher reduces > impact (there is effectively no collision / scheduling problem until you > get to extremely high port utilization) We could incorporate your text into this discussion as well. > > 4.3 > > not clear how this directly impacts multicast / except that a unicast > optimization ight seperately send to different STAs at different times. > optimization around long DTIM intervals to allow clients to sleep longer > clearly has impacts on performance, convergence time and how uch needs > to be sent which the device wakes up. It possibly deserves specific mention because multicast affects every STA and sometimes is transmitted periodically.  I guess this also falls into the category of problems that are not specific only to multicast, but which exact a particularly heavy penalty on multicast.  We should also say this (which I just found from a wireless-net tutorial) : When any single wireless client associated with an access point has /802.11/ power-save mode enabled, the access point buffers all /multicast frames/ and sends them only after the next DTIM (Delivery Traffic Indication Message) beacon. > 4.6 > > DMS is not currently implemented in products. > > work on and review of DMS > http://ieeexplore.ieee.org/document/7969670/?reload=true > http://eprints.networks.imdea.org/524/1/video_v01.pdf Thanks for the citations. > > 5.1 > > barely deals with ipv6, even though the problems are essntially the same. Good point.  This will require a good bit of textual revision to be applicable to IPv6. > > > - draft-mcbride-mboned-wifi-mcast-problem-statement-01 - > > 1. > > And many end devices are increasingly using > wifi for their connectivity. > > it's not really that this is a new and increasing alternative to wired > connectivity. there's no serious or common alternative to wirless 802.x > network usage. How about: Many end devices do not have any serious or common alternative to wireless 802.x for their connectivity. > > One of the primary problems multicast > over wifi faces is that link local 802.11 doesn't necessarily support > multicast, it supports broadcast. > > This is a possibly necessarily simplification, there are not naturally > great mechanisms within a common collision domain to limit reciever > membership so even the ability to limit membersship to recievers that > are part of the reciept naturally makes the air interface unavailable > for a time. I think that sentence needs to be significantly reworded.  Any suggested text will be appreciated. > > 4. > Apple's Bonjour protocol, for instance, provides service discovery > (for printing) > > mdns service discovery covers a great deal of (and increasing number) of > diverse services. most of them are more or less invisible to users, e.g. > they're not aware that they re using a service discovering mechanism, or > that autonomous deivces are using them irespective of user input. Your text might form a useful prologue for the sentence about Bonjour. Regards, Charlie P. --------------7F827E5419E36E0DBA231F2A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello Joel,

The [mboned] WG has adopted draft-ietf-mboned-ieee802-mcast-problems.  I have just posted an update that includes the relevant material from the earlier [intarea] individual submission, draft-perkins-intarea-multicast-ieee802, which you also reviewed.  I have some follow-up to your review comments below.


On 11/14/2017 6:36 PM, joel jaeggli wrote:
Greetings,

I have chosen to review both of these documents at this time as they
appear to me to be attempts to address the same problem space from the
vantage point of slightly different but overlapping communities
(evidenced by the authors) both of which have a vested interest in IP
multicast operation on ieee 802.xx wireless networks. This review is
seperated into the observations common to both followed by (limited)
commentary on each document.

While both documents address the challenges of arp / ND and aperiodic
multicast transmission,
draft-mcbride-mboned-wifi-mcast-problem-statement-01 has more focus on
application use of multicast above and beyond basic
subnet/adjacency/resource discovery applications.

draft-perkins-intarea-multicast-ieee802-03 takes a more technical and
nuanced look at the underlying 802.xx implementation of
multicast/broadcast packet transmission. It is oddly specific in some
areas to experiences gleaned from the IETF network, which while it may
be a product of our experience, is  by no means a unique environment,
and these challenges are to a great degree common or in fact worse  in
other wireless environments (where there might be more low powered
devices, less spectrum or radio coordination, a diversity of management
domains and so on.

The contents of that draft were pretty much contributed text from the co-authors, and there were a number of empty holes for future work.  But the future work kept not getting done.


it's not clear to me from the outset what the audience for an
eventually published document might be.

	Advice to implementors?

Yes.


	Feedback to the IEEE?

Not specifically, but the IEEE folks would definitely notice any work that we do.


	Operational advice?

Yes.


	Go from problem statment towards work on conclusions?

I am not sure about this.  For now I would put it as a lower priority, except insofar as bits of advice to implementers and operators would count as conclusions.


draft-perkins-intarea-multicast-ieee802-03  is the slightly more mature
document of the two,  I don't think that there is much justification for
advancing both given that they have fairly high overlap without being
complimentary, so I would encourage consolidation and coordination
between the int interests and those of the mbone/multicast community
towards something that is more than the union of the two.

Check.


>From my vantage-point the best outcome is one where the IETF provides
advice to vendors (becaue there are implementation specific tweaks and
optimation that can make many situations better) an the IEEE that
results in the employment of multicast being less disruptive and costly
and potentially to devices on wireless lans. work on ietf protocols
associated with arp/nd resource discovery to make them generally less
costly on the wire and more sensitive to power / cpu usage is a
desirable property as well pariticularly  of there are situations where
they can be avoided entirely (for example not having to defend addresses
via DAD because of something like
https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-13).

I very much agree with this.



Some comments specific to each document

- draft-perkins-intarea-multicast-ieee802-03 -

   	3.1.2.  Lower Data Rate

   	this rate might be as low as 6 Mbps, when
   	some unicast links in the same cell can be operating at rates up to
   	600 Mbps.

In fact backward compatibility and  multi-stream implementations mean
that the maximum unicast rates are currently up to a few Gb/s so there
can be a more than 3 order of magnitude difference in the transmission
rate from the basic rates to optimal unicast forwarding. some techinues
employed to increase spectral efficiency such a spatial multiplexing in
mimo systems are literally unavailable with more then one intended
reciever so it's not simply the case that nominal transmission rates
available are limited by backwards compatibility.

We could incorporate a version of your text into section 3.1.2 of the new revision.

	3.2.2. IPv6 issues

Respecting some of the cost of multicast on wireless networks these are
not strictly wireless problems reductions in the amount of signaling
required is better for the control-planes of routers, and for all hosts
ultimately, whether that is unicast RAs, prefix per host, or simply rate
limits on layer 2 learning e.g. https://tools.ietf.org/html/rfc6583
problems. 3.2.4 and 3.2.2 therefore are very much problems that extend
beyond the wireless domain.

Specifically with 3.2.4 the arp problem also applies to ND, in both
cases non-standard counter-measures (arp sponging unlearned entries as
in 5.1 for v4) various forms of off-net vs on-net driven ND suppression.


Do you think that the draft should avoid mention of problems that are not specific only to multicast, or should we mention them anyway along with the observation that they also extend beyond the wireless domain?


	On a wired network, there is not a huge difference amongst unicast,
	multicast and broadcast traffic;

Inadvertent flooded traffic or high amounts of ethernet multicast on
wired networks can be quite a bit less costly due to nic filtering, then
in cases where devices have to wake up effectively to process packets.
also the fact that these networks tend to be switched futher reduces
impact (there is effectively no collision / scheduling problem until you
get to extremely high port utilization)

We could incorporate your text into this discussion as well.


	4.3

not clear how this directly impacts multicast / except that a unicast
optimization ight seperately send to different STAs at different times.
optimization around long DTIM intervals to allow clients to sleep longer
clearly has impacts on performance, convergence time and how uch needs
to be sent which the device wakes up.

It possibly deserves specific mention because multicast affects every STA and sometimes is transmitted periodically.  I guess this also falls into the category of problems that are not specific only to multicast, but which exact a particularly heavy penalty on multicast.  We should also say this (which I just found from a wireless-net tutorial) :
When any single wireless client associated with an access point has 802.11 power-save mode enabled, the access point buffers all multicast frames and sends them only after the next DTIM (Delivery Traffic Indication Message) beacon.

	4.6

	DMS is not currently implemented in products.

work on and review of DMS
http://ieeexplore.ieee.org/document/7969670/?reload=true
http://eprints.networks.imdea.org/524/1/video_v01.pdf

Thanks for the citations.


	5.1

barely deals with ipv6, even though the problems are essntially the same.

Good point.  This will require a good bit of textual revision to be applicable to IPv6.



- draft-mcbride-mboned-wifi-mcast-problem-statement-01 -

	1.

	And many end devices are increasingly using
	wifi for their connectivity.

it's not really that this is a new and increasing alternative to wired
connectivity. there's no serious or common alternative to wirless 802.x
network usage.

How about:
        Many end devices do not have any serious or common alternative
	to wireless 802.x for their connectivity.



 	One of the primary problems multicast
   	over wifi faces is that link local 802.11 doesn't necessarily support
   	multicast, it supports broadcast.

This is a possibly necessarily simplification, there are not naturally
great mechanisms within a common collision domain to limit reciever
membership so even the ability to limit membersship to recievers that
are part of the reciept naturally makes the air interface unavailable
for a time.

I think that sentence needs to be significantly reworded.  Any suggested text will be appreciated.


	4.
   	Apple's Bonjour protocol, for instance, provides service discovery
   	(for printing)

mdns service discovery covers a great deal of (and increasing number) of
diverse services. most of them are more or less invisible to users, e.g.
they're not aware that they re using a service discovering mechanism, or
that autonomous deivces are using them irespective of user input.

Your text might form a useful prologue for the sentence about Bonjour.

Regards,
Charlie P.

--------------7F827E5419E36E0DBA231F2A-- From nobody Fri Feb 9 02:13:14 2018 Return-Path: X-Original-To: int-area@ietf.org Delivered-To: int-area@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A269127599; Fri, 9 Feb 2018 02:13:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: int-area@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151817119252.1184.6439924846894317506@ietfa.amsl.com> Date: Fri, 09 Feb 2018 02:13:12 -0800 Archived-At: Subject: [Int-area] I-D Action: draft-ietf-intarea-provisioning-domains-01.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 10:13:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group WG of the IETF. Title : Discovering Provisioning Domain Names and Data Authors : Pierre Pfister Eric Vyncke Tommy Pauly David Schinazi Filename : draft-ietf-intarea-provisioning-domains-01.txt Pages : 22 Date : 2018-02-09 Abstract: An increasing number of hosts access the Internet via multiple interfaces or, in IPv6 multi-homed networks, via multiple IPv6 prefix configurations. This document describes a way for hosts to identify such means, called Provisioning Domains (PvDs), with Fully Qualified Domain Names (FQDN). Those identifiers are advertised in a new Router Advertisement (RA) option and, when present, are associated with the set of information included within the RA. Based on this FQDN, hosts can retrieve additional information about their network access characteristics via an HTTP over TLS query. This allows applications to select which Provisioning Domains to use as well as to provide configuration parameters to the transport layer and above. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-intarea-provisioning-domains-01 https://datatracker.ietf.org/doc/html/draft-ietf-intarea-provisioning-domains-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-provisioning-domains-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 13 09:02:34 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B3312D847 for ; Tue, 13 Feb 2018 09:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFiw7nQ5F1oL for ; Tue, 13 Feb 2018 09:02:26 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57DE1120727 for ; Tue, 13 Feb 2018 09:02:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2038; q=dns/txt; s=iport; t=1518541346; x=1519750946; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=EUB408zSAmEcIVeQU7YezzM7Sx3rV2Y9QcabuwDsab0=; b=dzckDRF1/yqXObrS87cgvkc4j1ts6nCONV7g+kUgjwIUtuJeX9NX+a/9 0qvI1LAJjQjt7AKIde19OeP21u5FUKVV22Dd0yxwZxFUqO9x8cdip3E50 XH8VToRpNwxyAG4cbCNvBGRC8YMcrocO3Xz8dbu56kKGEH4WDrux5e5Tf 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdAgA/GYNa/5xdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNSZnAyg1uKJI4mgxmWQYIYCiOEAwEBgRMcgk5UGAECAQEBAQE?= =?us-ascii?q?BAmsdC4VNEToLEgEYCgImAgQwFRIEDoo6ELAagieFAYN8ghEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYEPg3KCFYFXgWgphjQBAQOFBTGCNAWkLgkCggeGF41klES?= =?us-ascii?q?OAolpAhEZAYE7AR85gVBwFT0qAYIchHaOHYEXAQEB?= X-IronPort-AV: E=Sophos;i="5.46,508,1511827200"; d="scan'208";a="355558829" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Feb 2018 17:02:25 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id w1DH2Pog014548 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 13 Feb 2018 17:02:25 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 13 Feb 2018 12:02:24 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Tue, 13 Feb 2018 12:02:24 -0500 From: "Eric Vyncke (evyncke)" To: "int-area@ietf.org" CC: Thierry Danis , Wenqin Shao Thread-Topic: What is new in -01 of PvD ? Comments are welcome Thread-Index: AQHTpOxrnNRUlXXe+k27y5uIW/VeFA== Date: Tue, 13 Feb 2018 17:02:24 +0000 Message-ID: <9980D080-9CFE-497E-A669-2D1C9918ADFC@cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.56.7] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Int-area] What is new in -01 of PvD ? Comments are welcome X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 17:02:33 -0000 V2UganVzdCBwdWJsaXNoZWQgdGhlIC0wMSBhcyBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1pbnRhcmVhLXByb3Zpc2lvbmluZy1kb21haW5zLTAxIGJhc2VkIG9uIHRoZSBj b21tZW50cyByZWNlaXZlZCBvbiB0aGUgbWFpbGluZyBsaXN0IGFuZCBkdXJpbmcgdGhlIGxhc3Qg V0cgbWVldGluZyBpbiBTaW5nYXBvcmUuDQoNCkhlcmUgaXMgdGhlIGxvZyBvZiBjaGFuZ2VzOg0K DQoxKSBUaGUgUHZEIFJBIE9wdGlvbiBtYXkgbm93IGNvbnRhaW4gb3RoZXIgUkEgb3B0aW9ucyBz dWNoIHRoYXQgUHZELWF3YXJlIGhvc3RzIG1heSByZWNlaXZlIGNvbmZpZ3VyYXRpb24gaW5mb3Jt YXRpb24gb3RoZXJ3aXNlIGludmlzaWJsZSB0byBub24tUHZELWF3YXJlIGhvc3RzLiBfU28gdGhl IFB2RCBJRCBvcHRpb24gaXMgbm93IGEg4oCYY29udGFpbmVy4oCZXw0KDQoyKSBDbGFyaWZ5IHRo YXQgdGhlIGFkZGl0aW9uYWwgUHZEIEFkZGl0aW9uYWwgSW5mb3JtYXRpb24gaXMgbm90IGludGVu ZGVkIHRvIG1vZGlmeSBob3N0J3MgbmV0d29ya2luZyBzdGFjayBiZWhhdmlvciwgYnV0IHJhdGhl ciBwcm92aWRlIGluZm9ybWF0aW9uIHRvIHRoZSBBcHBsaWNhdGlvbiwgdXNlZCB0byBzZWxlY3Qg d2hpY2ggUHZEcyBtdXN0IGJlIHVzZWQgYW5kIHByb3ZpZGUgY29uZmlndXJhdGlvbiBwYXJhbWV0 ZXJzIHRvIHRoZSB0cmFuc3BvcnQgbGF5ZXIuDQoNCjMpIFRoZSBSQSBvcHRpb24gcGFkZGluZyBp cyB1c2VkIHRvIGluY3JlYXNlIHRoZSBvcHRpb24gc2l6ZSB0byB0aGUgbmV4dCA2NCAod2FzIDMy KSBiaXRzIGJvdW5kYXJ5Lg0KDQo0KSBSZW1vdmluZyByZWZlcmVuY2VzIHRvICdtZXRlcmVkJyBh bmQgJ2NoYXJhY3RlcmlzdGljcycga2V5cy4gVGhvc2UgbWF5IGJlIGluIHNjb3BlIG9mIHRoZSBQ dkQgd29yaywgYnV0IHRoaXMgZG9jdW1lbnQgd2lsbCBmb2N1cyBvbiBlc3NlbnRpYWwgcGFydHMg b25seS4NCg0KNSkgUmVtb3ZpbmcgYXBwZW5kaXggc2VjdGlvbiByZWdhcmRpbmcgbGluayBxdWFs aXR5IGFuZCBiaWxsaW5nIGluZm9ybWF0aW9uLg0KDQo2KSBCZXR0ZXIgZGV0YWlsIHRoZSBTZWN1 cml0eSBtb2RlbCBhbmQgUHJpdmFjeSBjb25zaWRlcmF0aW9ucy4NCg0KDQpXZSBoYXZlIHJ1bm5p bmcgY29kZSBvbiBMaW51eCBrZXJuZWwgKyBSQURWRCArIE9ESENQICsgd2lyZXNoYXJrIHRoYW5r cyB0byBXZW5xaW4gU2hhbyAmIFBpZXJyZSBQZmlzdGVyIChiYXNlZCBvbiBwcmV2aW91cyB3b3Jr IG9mIFRoaWVycnkgRGFuaXMpLg0KDQoqV2l0aCB0aGUgYWJvdmUgY2hhbmdlcywgd2Ugd2lsbCBh c2sgZm9yIGEgSUFOQSBhbGxvY2F0aW9uIG9mIHRoZSBQdkQgSUQgb3B0aW9uIG5leHQgd2Vlay4q DQoNClRoYW5rIHlvdSBmb3IgcmV2aWV3aW5nIHRoZSBkb2N1bWVudCBhbmQgY29tbWVudGluZyBp dCBvbiB0aGUgbWFpbGluZyBsaXN0DQoNCi3DqXJpYywgcGllcnJlLCB0b21teSBhbmQgZGF2aWQN Cg0KDQo= From nobody Mon Feb 19 08:58:13 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85DD2126CD8 for ; Mon, 19 Feb 2018 08:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Zi3Ozf0Q; dkim=pass (1024-bit key) header.d=ericsson.com header.b=c9Vk1VIg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaN7N4IICNNf for ; Mon, 19 Feb 2018 08:58:11 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34153126C0F for ; Mon, 19 Feb 2018 08:58:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519059488; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=AITiGBggRAn5WaxYuMXtBNUP12lJ5JXJktY+T4Y1eWs=; b=Zi3Ozf0Qd0ieHG1bZyxpLHYAzLq7AM8c1rJwZ5xr9VXCzbZIBkO4XL4JVDLAHgvt Jn3PaLtI3RMwr5SRY0d3OMqzk31VHNbXo0GY3IKLQYflaoqiLkzCZ4tF9HNxGI3G 2ofbcEyxgQ0FG8KGo8dgv4FSmT4Jzn6HPVLqI+b+60s=; X-AuditID: c1b4fb2d-4b1ff70000005540-f6-5a8b0220f769 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6E.F4.21824.0220B8A5; Mon, 19 Feb 2018 17:58:08 +0100 (CET) Received: from ESESSMR502.ericsson.se (153.88.183.110) by ESESSHC023.ericsson.se (153.88.183.87) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 19 Feb 2018 17:58:08 +0100 Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMR502.ericsson.se (153.88.183.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Mon, 19 Feb 2018 17:58:08 +0100 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26 via Frontend Transport; Mon, 19 Feb 2018 17:58:07 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AITiGBggRAn5WaxYuMXtBNUP12lJ5JXJktY+T4Y1eWs=; b=c9Vk1VIgMB4Xpn4gVv5WKYwc1g9ddrglmUrzCeqZlpfJe/j4AF/EPsIchJIP+rdsiNg2JdM5HPQ2nBIJxI5pAbdlp/ZDdV6SoxD+eg+lKHs/DjgviAX72QHuXelOrQoqmB8ZtkA4anC5sQU9DjuiuXZd9ue+S/yrZ8Sw9P3ZZHc= Received: from CO2PR15MB0090.namprd15.prod.outlook.com (10.161.86.156) by CO2PR15MB0106.namprd15.prod.outlook.com (10.161.86.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Mon, 19 Feb 2018 16:58:05 +0000 Received: from CO2PR15MB0090.namprd15.prod.outlook.com ([10.161.86.156]) by CO2PR15MB0090.namprd15.prod.outlook.com ([10.161.86.156]) with mapi id 15.20.0464.016; Mon, 19 Feb 2018 16:58:03 +0000 From: Wassim Haddad To: "int-area@ietf.org" CC: Wassim Haddad , "intarea-chairs@ietf.org" Thread-Topic: [Int-area] Call for Agenda Items @ IETF101 Thread-Index: AQHTqaLObjFkkNfLfEOuQFT011G65g== Date: Mon, 19 Feb 2018 16:58:03 +0000 Message-ID: <7A914532-A9EB-4A06-86AE-4072EB8333C1@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=wassim.haddad@ericsson.com; x-originating-ip: [129.192.183.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO2PR15MB0106; 7:mWV/EG0/uV1iwkztWsNaJ2BJQxjN3x4tHCR+YLQ+Au/5kMiFAG2DqHBJp7cIi8Ektrg7CieShllYkW4Es9mn+GW1mlpB97Z97Kz2jjy0NE3dryykWRCDtoSRNN60zPpIPWJrilpEbScHYQUC8xAPstHMLsO105KrkRTt82WsT/cS1GhaPtCS0wofzc0l84qLzceAq22jh4i1bSGusNxxCs5nbruDTWY5qMtqbM/dwE+hyZ8qoKymBWJJcXkgvHWX x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(39380400002)(376002)(39860400002)(396003)(346002)(366004)(189003)(199004)(25786009)(81156014)(558084003)(33656002)(186003)(68736007)(97736004)(450100002)(54906003)(5660300001)(66066001)(6512007)(106356001)(2351001)(86362001)(6486002)(81166006)(77096007)(6116002)(478600001)(7736002)(105586002)(4326008)(8936002)(53936002)(3846002)(6916009)(99286004)(83716003)(14454004)(305945005)(8676002)(36756003)(1857600001)(82746002)(2501003)(316002)(6506007)(3660700001)(2900100001)(2906002)(6436002)(26005)(102836004)(5640700003)(3280700002)(413944005); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR15MB0106; H:CO2PR15MB0090.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: 99c617f6-c1ea-4a8f-f9a9-08d577b9f0c2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:CO2PR15MB0106; x-ms-traffictypediagnostic: CO2PR15MB0106: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231101)(2400082)(944501161)(10201501046)(3002001)(6041288)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:CO2PR15MB0106; BCL:0; PCL:0; RULEID:; SRVR:CO2PR15MB0106; x-forefront-prvs: 0588B2BD96 received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: JDjlIx1E/NU9W9ni2hPZZ/1fHx2CvlfZuzxdPb/aX5Pzd4jF8XJR+oka+vdpKW1HOcyikeCB3Bp/OpJtzd0pxUniKtUEqqr9HS9Q2uOyZGHc0/g2NjZAFdorjLB/MBP7yXjiwytrk2D8kCwNxSgJ/gA2MDtePeoUSLF/5SdQzoY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 99c617f6-c1ea-4a8f-f9a9-08d577b9f0c2 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2018 16:58:03.1476 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR15MB0106 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA01Se0hTURjv3Me8Ww1uS9unEYuR/0xdmkVGUglFFvagkHRUesmLitvUXZOM CEOhmmmiZk4LjaaWjwU5ypxMpyG+0qgIE0XRBYpUZM1VgrXtaPTf7/X9vnMOhyFlxXQQk67P 4Q16TqsUSShTwouzYduIIk34xL2IqLHqj1RUzfSxg0Ss2fyLOIU0kugUXpueyxt27E+WpD22 OcgsF7p8o7yMzEe9yIjEDLC7oMP+hDQiCSNjexHYXl73w8SKoGrYRGPiRvC8fJHApJ6Ab11u kZdQ7CIBprY2ylsmYysJePclGqf6EPR1l/m2iNhwcDW+pr3Ynw2BLme3b4BkeaipmCK9eBMb CVPWB57ljCcTBa2O0ziuBvOKnfbKFBsMza06ryxlD8BERZevHbGbwT3YQuBGOYw7awl8NxbM naMkxgEwP7tC4/x5yL/rEmFdCZ+XmiiMt8Lb2iLkPT6wVgLeW000NiLBWNpJY2OOhpnutdbj 0DJ8h8RGP4Kijq+rq1Xwp+n76nQGWApu/9Nvvqom8EAVCSXj/VQpCq/+7+gYh0KdbVGEcSw0 3u/wwzgEGh4ukNW+J9gIAyYnVYfoJhQg8IKgS90ZqeYN6RcFIVOv1vM5z5Dnkzisy2HtqHkh pgexDFJukP5YNmpkNJcr5Ol6EDCk0l8aN+aRpClc3hXekJlkuKTlhR60haGUcunAUalGxqZy OXwGz2fxhjWXYMRB+Uh+uLRgz3LeCfWjW8khs4Pr9g5NirinJxN+TlbGu7IvxK1PtFtCJ9i5 wlrOMq2ztKZ00tcStZ/2iZ3xxcNLuw8FJmmXPqhjxIpsxfyRNwPbaxxBqapATu7OHSkZmTzT EJyrMBrtDS22ZqHQVH9f8zur/WpV40ytomBUFRx2bkhJCWlchIo0CNxfhiPASSADAAA= Archived-At: Subject: [Int-area] Call for Agenda Items @ IETF101 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 16:58:12 -0000 Dear all, In preparation for the Intarea WG meeting scheduled on Monday 03/19, please= send agenda requests to the chairs.=20 Please indicate short abstract, draft name, and time requested. Thanks, Juan Carlos, Suresh and Wassim= From nobody Mon Feb 19 11:16:02 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CD9126DFF for ; Mon, 19 Feb 2018 11:15:51 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKRL51p_nSOB for ; Mon, 19 Feb 2018 11:15:50 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B79E312785F for ; Mon, 19 Feb 2018 11:15:48 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id z81so17082004wmb.4 for ; Mon, 19 Feb 2018 11:15:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=c7ov5biMHiie1tUllh4X/6Jf9l6qMxJu7stNdvACvYc=; b=ZTCHBLMQvuqRsBVPIUl4GnoLC5h4qV06FvxAjYN7iCMQpCf2hgnh0xgU01NJ8w9XwQ QG0DmslDgU3YOujEdSG9Bql56Z5/Se6ZSpuBnqDyblGT+5jyTf9BylfEzRnBXdhRMtHn 1AfrPjMVlRlwenvVoQ/gLBXKJgYfV4VUdP9o3GfnEIMkCrYT0kJLDr00BxAFxtSTdaDD mx8bY4WM/sVijd59D7KSRcKbpITQ+AgeLOEaBWL6KodZtjtJNl5yT9WpfqwpQCDF37u9 1gI7cuWjELL/n7IKJRfP2/f3p3UeuMQt9iNqBoockvFdhKfSWx3gwb84yXKIEuvtIGDv oAyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=c7ov5biMHiie1tUllh4X/6Jf9l6qMxJu7stNdvACvYc=; b=tvRXCuuA+LsXAOZscJS6X2b48iQw/j3zuK7JW4Azj24rMvXhjJetWL1kFLWxzQEmbr 77AMVhWCsweTj0WSuVvh2G9hk5uPz2Xi4MHe5cwj56lYeTWJ5+yjYLakB9fJYBeYZdMQ r2yFBgcjxrTuwPG3EQyy4tOutWm1CQMYoLySSenchcfD7oNgZjapeHhkooKZdDz3eLuF 6ysDBKBKyVFXpFggK9IFMzhQhcL1VT4bqQ4LEq+Qt5EK1C3Gcn7zT/FU2anTsOyCExe7 H5ANaSO4BPbkFxBx6NODulvd248I0iZ7Igw6eS8FuN58vOF4yxnY5fh6zU+1o3lj/UMI oASw== X-Gm-Message-State: APf1xPCIZPh2PiBcEiYiQwiRIgGx8IVxc/UfdXLY6oSY1/TWQLuv9DGB ubmES52C/bu7TXj7AeNQBMTt0bHCr07qXdSSfF9lgzP4 X-Google-Smtp-Source: AH8x226Z+vkCaQuJXd/B5k9QE4Y6xtTUiuxwubcaCWbZHC34fcS59wRG2UotbfKGR4LY9TAVbca42310+xGKSAlEUVM= X-Received: by 10.28.48.11 with SMTP id w11mr13323724wmw.59.1519067746488; Mon, 19 Feb 2018 11:15:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.142.142 with HTTP; Mon, 19 Feb 2018 11:15:46 -0800 (PST) In-Reply-To: <151906718318.18731.8986618406430268357.idtracker@ietfa.amsl.com> References: <151906718318.18731.8986618406430268357.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Mon, 19 Feb 2018 11:15:46 -0800 Message-ID: To: int-area@ietf.org, ila@ietf.org, 5GANGIP <5gangip@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Int-area] Fwd: New Version Notification for draft-herbert-ipv6-prefix-address-privacy-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 19:15:52 -0000 Hello, This draft discusses issue of privacy in IPv6 network prefix assignment. Specifically the privacy problems of an assigned network prefix becoming a persistent identifier for devices (e.g. /64 assignment to devices in mobile networks). The use of identifier/locator split is suggested as a solution. Thanks, Tom ---------- Forwarded message ---------- From: Date: Mon, Feb 19, 2018 at 11:06 AM Subject: New Version Notification for draft-herbert-ipv6-prefix-address-privacy-00.txt To: Tom Herbert A new version of I-D, draft-herbert-ipv6-prefix-address-privacy-00.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-ipv6-prefix-address-privacy Revision: 00 Title: Privacy in IPv6 Network Prefix Assignment Document date: 2018-02-20 Group: Individual Submission Pages: 17 URL: https://www.ietf.org/internet-drafts/draft-herbert-ipv6-prefix-address-privacy-00.txt Status: https://datatracker.ietf.org/doc/draft-herbert-ipv6-prefix-address-privacy/ Htmlized: https://tools.ietf.org/html/draft-herbert-ipv6-prefix-address-privacy-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-herbert-ipv6-prefix-address-privacy-00 Abstract: This document discusses privacy concerns around network prefix assignment in IPv6. It evaluates the privacy threat, proposes a set of ideal criteria for strong privacy, and suggests solutions to achieve a high degree of privacy in addressing. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Feb 20 00:06:42 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACC61243F3; Tue, 20 Feb 2018 00:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJTMM5Nwyf0G; Tue, 20 Feb 2018 00:06:35 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B8A1124239; Tue, 20 Feb 2018 00:06:34 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id k87so19570292wmi.0; Tue, 20 Feb 2018 00:06:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=59JNgE0vq3hcX8NOyJA9YXmQpnu9iZ9An76hedGxDtg=; b=vF/M9wnpNJkrk7DPji8MINyZuemWrD3+/pYIvBRVSObUkVAgSE91Z3t+UVuKeXt3aV aMK2HNxmiOCpNf3t70OZJUdRCivrunFXPqyUnwOdMymI0BWgdfbyALjf+zvhpdHFTGz9 8Qc3Wv9xR8D9ls9xVizOCyG44lluHkTMoeA9qoSZJC0IoW9ogWsc5d9oc2tT6ZSnyYk6 v19S8xS81Cym3PQI+VITFtb4koCP6SLLuOSV/+cOCecdNULB00jHoou3SUYCGMDf97Iw dEM2rWGfavAmt7qQ8nIuPsDxK2MNDORCQ+p2EdpOEsEFTH5YSfLcti/nJxkkOrxC6SSR d0LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=59JNgE0vq3hcX8NOyJA9YXmQpnu9iZ9An76hedGxDtg=; b=MVq3VH/16+QrPHdczQvEDGyzNsvfFt8ewf8GvkVmGH4qMCAdNP1FGtM4yVKSXy/0LC oK17cTzJXXiFpNlhVYom/Q8eOtw7Q5RJk/vbxHGqnJzeZYJIJbk7AMJUoQtUIpRJyRaD ePcbv1Pb2XFY3epowc+oaD9cW6EYcEDIhlApciC2gtARpumkO/Kor3h0oyk05eZ++cH7 Zoa2kYVRlvywnGUX8jweoohI7CazfaM/Ltd6lEpxLNLVMhQ1H1gvMSH6o0SdCA4uCmqE 40p8/4TkVbVmxTZ7m3lyzQQzUPFJz4wHuzr36LnYVWLZOqO2m5VAxeSsgNImdk+gm5CQ uW+Q== X-Gm-Message-State: APf1xPBXTxVB079W03nhzd9cILNeIKr+5P/XPA8NkjDHodH96wmDiy8h YqiKDSseR0JBvgrPbE7XlKd61/cOA1Sy14ylgYtM7A== X-Google-Smtp-Source: AH8x224pVLdm/zolydAVQwV/8AMs3+chpcVo/Vk2mKvcQCHTKfb61sKeu4CvHLyeMSR2O7o39FJs2kN56JIlTOm/+Gg= X-Received: by 10.28.91.68 with SMTP id p65mr13030229wmb.119.1519113993277; Tue, 20 Feb 2018 00:06:33 -0800 (PST) MIME-Version: 1.0 Sender: crowcroft@gmail.com Received: by 10.28.153.147 with HTTP; Tue, 20 Feb 2018 00:06:32 -0800 (PST) In-Reply-To: References: <151906718318.18731.8986618406430268357.idtracker@ietfa.amsl.com> From: Jon Crowcroft Date: Tue, 20 Feb 2018 08:06:32 +0000 X-Google-Sender-Auth: CT4TxbyBiNqroWNkbsOoZdAWWuA Message-ID: To: Tom Herbert Cc: int-area@ietf.org, ila@ietf.org, 5GANGIP <5gangip@ietf.org> Content-Type: multipart/alternative; boundary="001a11442262f154de0565a0491a" Archived-At: Subject: Re: [Int-area] [5gangip] Fwd: New Version Notification for draft-herbert-ipv6-prefix-address-privacy-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 08:06:37 -0000 --001a11442262f154de0565a0491a Content-Type: text/plain; charset="UTF-8" people may already have read this (and its a while back) but interesting to see the limited but non zero use of privacy v6 addr https://www.akamai.com/uk/en/multimedia/documents/technical-publication/temporal-and-spatial-classification-of-active-ipv6-addresses-technical-publication.pdf On Mon, Feb 19, 2018 at 7:15 PM, Tom Herbert wrote: > Hello, > > This draft discusses issue of privacy in IPv6 network prefix > assignment. Specifically the privacy problems of an assigned network > prefix becoming a persistent identifier for devices (e.g. /64 > assignment to devices in mobile networks). The use of > identifier/locator split is suggested as a solution. > > Thanks, > Tom > > > ---------- Forwarded message ---------- > From: > Date: Mon, Feb 19, 2018 at 11:06 AM > Subject: New Version Notification for > draft-herbert-ipv6-prefix-address-privacy-00.txt > To: Tom Herbert > > > > A new version of I-D, draft-herbert-ipv6-prefix-address-privacy-00.txt > has been successfully submitted by Tom Herbert and posted to the > IETF repository. > > Name: draft-herbert-ipv6-prefix-address-privacy > Revision: 00 > Title: Privacy in IPv6 Network Prefix Assignment > Document date: 2018-02-20 > Group: Individual Submission > Pages: 17 > URL: > https://www.ietf.org/internet-drafts/draft-herbert-ipv6- > prefix-address-privacy-00.txt > Status: > https://datatracker.ietf.org/doc/draft-herbert-ipv6-prefix- > address-privacy/ > Htmlized: > https://tools.ietf.org/html/draft-herbert-ipv6-prefix-address-privacy-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-herbert-ipv6- > prefix-address-privacy-00 > > > Abstract: > This document discusses privacy concerns around network prefix > assignment in IPv6. It evaluates the privacy threat, proposes a set > of ideal criteria for strong privacy, and suggests solutions to > achieve a high degree of privacy in addressing. > > > > > 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 > > _______________________________________________ > 5gangip mailing list > 5gangip@ietf.org > https://www.ietf.org/mailman/listinfo/5gangip > --001a11442262f154de0565a0491a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
people may already have read this (and its a while back) b= ut interesting to see the limited but non zero use of privacy v6 addr
<= a href=3D"https://www.akamai.com/uk/en/multimedia/documents/technical-publi= cation/temporal-and-spatial-classification-of-active-ipv6-addresses-technic= al-publication.pdf">https://www.akamai.com/uk/en/multimedia/documents/techn= ical-publication/temporal-and-spatial-classification-of-active-ipv6-address= es-technical-publication.pdf
=
On Mon, Feb 19, 2018 at 7:15 PM, Tom Herbert= <tom@quantonium.net> wrote:
Hello,

This draft discusses issue of privacy in IPv6 network prefix
assignment. Specifically the privacy problems of an assigned network
prefix becoming a persistent identifier for devices (e.g. /64
assignment to devices in mobile networks).=C2=A0 The use of
identifier/locator split is suggested as a solution.

Thanks,
Tom


---------- Forwarded message ----------
From:=C2=A0 <internet-drafts= @ietf.org>
Date: Mon, Feb 19, 2018 at 11:06 AM
Subject: New Version Notification for
draft-herbert-ipv6-prefix-address-privacy-00.txt
To: Tom Herbert <tom@quantonium.ne= t>



A new version of I-D, draft-herbert-ipv6-prefix-address-privacy-00.txt=
has been successfully submitted by Tom Herbert and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-herbert-ipv6-prefix-address-privacy
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Privacy in IPv6 Network Prefix Ass= ignment
Document date:=C2=A0 2018-02-20
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 17
URL:
https://www.iet= f.org/internet-drafts/draft-herbert-ipv6-prefix-address-privacy-0= 0.txt
Status:
https://datatracker.ietf.= org/doc/draft-herbert-ipv6-prefix-address-privacy/
Htmlized:
https://tools.ietf.org/html/= draft-herbert-ipv6-prefix-address-privacy-00
Htmlized:
https://datatracke= r.ietf.org/doc/html/draft-herbert-ipv6-prefix-address-privacy-00<= /a>


Abstract:
=C2=A0 =C2=A0This document discusses privacy concerns around network prefix=
=C2=A0 =C2=A0assignment in IPv6. It evaluates the privacy threat, proposes = a set
=C2=A0 =C2=A0of ideal criteria for strong privacy, and suggests solutions t= o
=C2=A0 =C2=A0achieve a high degree of privacy in addressing.




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

_______________________________________________
5gangip mailing list
5gangip@ietf.org
https://www.ietf.org/mailman/listinfo/5gangip<= br>

--001a11442262f154de0565a0491a-- From nobody Tue Feb 20 02:05:11 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C901124217 for ; Tue, 20 Feb 2018 02:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNAXdeGoqj71 for ; Tue, 20 Feb 2018 02:05:08 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DBF01200E5 for ; Tue, 20 Feb 2018 02:05:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6378; q=dns/txt; s=iport; t=1519121108; x=1520330708; h=from:to:cc:subject:date:message-id:mime-version; bh=zPR4ZoPVVOzPGTI7dTFgPA6QuvUn6FCq8wuEmuGz/00=; b=K3hmQ6RzywYq7LmpPaIe1axBtjIlQv7xOUc4OJjIQxHbFTevW1QDJbAG c7dTam/dQ7CXHe5xqAThNhNNGiK/Ycaq0fmKShgCFgFdu4hOoFrPFxzPK peJnCE1LYlfqOQBMJztH6eCqwb7pZQzvhp//kGYP3qmllnPBs2Usy31+9 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BkAgDn8Yta/5BdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJadWZwKAqDXZgrgxmQbYdyChgBCoRJTxyCR1gUAQIBAQEBAQE?= =?us-ascii?q?Cax0LhSYFASEmMBIBSgIEJQsnBA6JQ2QQsCuCJyaEW4N/ghMBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEdhQ2CKIFXgWgphE6BZwEBgi+CWTGCNAWkNQkCggiGGo1mlEe?= =?us-ascii?q?OBolsAhEZAYE7ATYigVFwFWQBgggBAQ4JgleCFngBjECBGQEBAQ?= X-IronPort-AV: E=Sophos; i="5.46,538,1511827200"; d="scan'208,217"; a="73204703" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Feb 2018 10:05:07 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w1KA57FE029496 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Feb 2018 10:05:07 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 20 Feb 2018 05:05:06 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Tue, 20 Feb 2018 05:05:06 -0500 From: "Eric Vyncke (evyncke)" To: "int-area@ietf.org" CC: "Pierre Pfister (ppfister)" , Tom Jones Thread-Topic: Hackathon about PvD at IETF-101 Thread-Index: AQHTqjJIq38Nt96gc0GaA40LrVIjBA== Date: Tue, 20 Feb 2018 10:05:06 +0000 Message-ID: <8B2B1A59-7DDC-42D2-A660-A954BEB0368A@cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.56.12] Content-Type: multipart/alternative; boundary="_000_8B2B1A597DDC42D2A660A954BEB0368Aciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Int-area] Hackathon about PvD at IETF-101 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 10:05:10 -0000 --_000_8B2B1A597DDC42D2A660A954BEB0368Aciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgeW91IHdhbnQgdG8gdGVzdCB5b3VyIFB2RCAoZHJhZnQtaWV0Zi1pbnRhcmVhLXByb3Zpc2lv bmluZy1kb21haW5zKSBpbXBsZW1lbnRhdGlvbiwgb3IgaGVscCB3aXRoIHRoZSBpbnRlZ3JhdGlv biBvZiBQdkQgaW50byBORUFUIHByb2plY3QgKEVVLWZ1bmRlZCBIMjAyMCB3d3cubmVhdC1wcm9q ZWN0LmV1KSB0aGVuIHlvdSBhcmUgd2VsY29tZSB0byBwYXJ0aWNpcGF0ZSB0byB0aGUgZnJlZSBo YWNrYXRob24gb24gdGhlIFdFIGJlZm9yZSB0aGUgSUVURi0xMDEuDQoNCg0KDQpPcGVuIHNvdXJj ZSBjb2RlOiBodHRwczovL2dpdGh1Yi5jb20vSVB2Ni1tUHZEICgyIGRhZW1vbnMgc2VuZGluZyBS QSArIExpbnV4IEtlcm5lbCB0byBoYW5kbGUgUHZEKQ0KDQoNCg0KTW9yZSBpbmZvcm1hdGlvbiBh Ym91dCB0aGUgaGFja2F0aG9uOg0KDQogICAgICAgICAgICBTaWdudXA6IGh0dHBzOi8vd3d3Lmll dGYub3JnL3JlZ2lzdHJhdGlvbi9pZXRmMTAxL2hhY2thdGhvbnJlZ2lzdHJhdGlvbi5weQ0KDQog ICAgICAgICAgICBNb3JlIGluZm9ybWF0aW9uOiBodHRwczovL2lldGYub3JnL2hvdy9ydW5uaW5n Y29kZS9oYWNrYXRob25zLzEwMS1oYWNrYXRob24vDQoNCiAgICAgICAgICAgIEtlZXAgdXAgdG8g ZGF0ZSBieSBzdWJzY3JpYmluZyB0bzoNCg0KICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9oYWNrYXRob24NCg0KDQoNCg0KDQotw6lyaWMsIC1waWVycmUg YW5kIC10b20NCg0KDQoNCg0KDQoNCg== --_000_8B2B1A597DDC42D2A660A954BEB0368Aciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <7771D120CECA37429B2C4E8E261B1778@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZv bnQtZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0 eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseTpDYWxpYnJpO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4w cHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGlu az0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPklmIHlvdSB3YW50IHRvIHRlc3QgeW91ciBQdkQgKGRy YWZ0LWlldGYtaW50YXJlYS1wcm92aXNpb25pbmctZG9tYWlucykgaW1wbGVtZW50YXRpb24sIG9y IGhlbHAgd2l0aCB0aGUgaW50ZWdyYXRpb24gb2YgUHZEIGludG8gTkVBVCBwcm9qZWN0IChFVS1m dW5kZWQgSDIwMjAgd3d3Lm5lYXQtcHJvamVjdC5ldSkgdGhlbiB5b3UgYXJlIHdlbGNvbWUgdG8g cGFydGljaXBhdGUgdG8gdGhlIGZyZWUgaGFja2F0aG9uDQogb24gdGhlIFdFIGJlZm9yZSB0aGUg SUVURi0xMDEuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk9wZW4gc291cmNlIGNvZGU6 IDxzcGFuIGxhbmc9IkZSIj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vSVB2Ni1tUHZEIj48 c3BhbiBsYW5nPSJFTi1VUyI+aHR0cHM6Ly9naXRodWIuY29tL0lQdjYtbVB2RDwvc3Bhbj48L2E+ PC9zcGFuPiAoMiBkYWVtb25zIHNlbmRpbmcgUkEgJiM0MzsgTGludXggS2VybmVsIHRvIGhhbmRs ZSBQdkQpPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Nb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBoYWNr YXRob246PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg U2lnbnVwOiZuYnNwO2h0dHBzOi8vd3d3LmlldGYub3JnL3JlZ2lzdHJhdGlvbi9pZXRmMTAxL2hh Y2thdGhvbnJlZ2lzdHJhdGlvbi5weTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IE1vcmUgaW5mb3JtYXRpb246Jm5ic3A7aHR0cHM6Ly9pZXRmLm9yZy9o b3cvcnVubmluZ2NvZGUvaGFja2F0aG9ucy8xMDEtaGFja2F0aG9uLzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEtlZXAgdXAgdG8gZGF0ZSBieSBzdWJz Y3JpYmluZyB0bzombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaGFj a2F0aG9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LcOpcmljLCAtcGll cnJlIGFuZCAtdG9tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8B2B1A597DDC42D2A660A954BEB0368Aciscocom_-- From nobody Tue Feb 20 22:32:31 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD8212E86E for ; Tue, 20 Feb 2018 22:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksV3c_NjDo8T for ; Tue, 20 Feb 2018 22:32:26 -0800 (PST) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E6281270A7 for ; Tue, 20 Feb 2018 22:32:26 -0800 (PST) Received: by mail-wr0-x230.google.com with SMTP id k9so1218139wre.9 for ; Tue, 20 Feb 2018 22:32:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EleMX5BnEM3FBf4RR3tFWyIRrpLUO9EM9MHsNA8srj8=; b=kdF92BQf1uG1zJCYpcX6fThg2GazN+7GYCvQukJktAIqH3sjixtQv1pEQ3ZICPHiOK kl8bJtJ3p+exw0jPjlm1T3Zlkqc8qpNn4GyWhwbhRsAHAtqEMR/lcJRJgdmJuFlxjVr3 DqXaJIjnkpsJD3/xfgjzqIOmDaaJGzzrYji8JsaMwJQLRh1gy2f3Gdqqc9EDPQhhSPzo JOUfAEj3Yrz/+x3v24BlIxjyrIkLb8SsgIG3M3rHNPthYOCtWB73nAnsf+/ihVbYxryA wCoRdKeEToWtzOGHd1GaoWQST91ah2DVWp/cm6Pd8cnQq2W0PLWvMa8AJlJrw81qARyp 2oBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EleMX5BnEM3FBf4RR3tFWyIRrpLUO9EM9MHsNA8srj8=; b=GI/fIQjqkb2cvQumcQ2Y08BYD5KDx9pZvKfhGzcklN0Ty9+JtazBR03qDKmVnMKDAt 0zkCC2KYvG+1NSTVqfn6Vd+TQ8dJ/h2X8oWr26aI7GeV2vWXBq5oNsnx4pYWvFoInfKq 540pvyU9PRTiN7itOGTOUegHBetp9KobFkSVE8ysIhiox4nR8H4KlNJ9pMBdqA8fqmRE mrF/aVXri27d3NPsjA7TE/juE86HxUjK3fBQ+Bsrpll/It+oZ+SDzZ71KUrHJ2kGGIWA rKSnmKtj66QNxxdatOsApQmTdWxPIya72QSLXFfX57dwux/PhNbjY9E7GeHs31/X+u6N wvoA== X-Gm-Message-State: APf1xPBb5QE+umo0hToNY0Nx+R6y5qxY+FV3g2KWngci43egG9HPJzy3 j2TcwuWGxHl8L9taHrQO0wcE1Woo5nFovpOTuUIUTQ== X-Google-Smtp-Source: AH8x227gTaMKpldid0r6SCZoZrobnZd3V0ZOrpniZdu/c2uKMGS+ZNwKlxpLr/Dh3Ri9d96Z4bRCyzgj7uoPx8PrN8o= X-Received: by 10.223.131.133 with SMTP id 5mr1714198wre.153.1519194744638; Tue, 20 Feb 2018 22:32:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.142.142 with HTTP; Tue, 20 Feb 2018 22:32:24 -0800 (PST) Received: by 10.223.142.142 with HTTP; Tue, 20 Feb 2018 22:32:24 -0800 (PST) In-Reply-To: References: <151906718318.18731.8986618406430268357.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Tue, 20 Feb 2018 22:32:24 -0800 Message-ID: To: Jon Crowcroft Cc: int-area@ietf.org, ila@ietf.org, 5GANGIP <5gangip@ietf.org> Content-Type: multipart/alternative; boundary="94eb2c0d29401961b00565b31776" Archived-At: Subject: Re: [Int-area] [5gangip] Fwd: New Version Notification for draft-herbert-ipv6-prefix-address-privacy-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 06:32:29 -0000 --94eb2c0d29401961b00565b31776 Content-Type: text/plain; charset="UTF-8" Jon, Thanks for the reference. I think that both spatial and temporal characteristics should be part of strong privacy addresses. Will update the draft to mention those. One thing that I'm not sure how to quantify yet is the effects of using addresses for narrow purposes like a single flow. For instance, if a packet is seen with some address that might not be useful as a target of attack by trying to connect to the address. No application would be listening on such addresses (although this does make ICMP interesting, like whether there should be a response to echo request). Tom On Feb 20, 2018 2:06 AM, "Jon Crowcroft" wrote: people may already have read this (and its a while back) but interesting to see the limited but non zero use of privacy v6 addr https://www.akamai.com/uk/en/multimedia/documents/technical-publication/ temporal-and-spatial-classification-of-active-ipv6-addresses-technical- publication.pdf On Mon, Feb 19, 2018 at 7:15 PM, Tom Herbert wrote: > Hello, > > This draft discusses issue of privacy in IPv6 network prefix > assignment. Specifically the privacy problems of an assigned network > prefix becoming a persistent identifier for devices (e.g. /64 > assignment to devices in mobile networks). The use of > identifier/locator split is suggested as a solution. > > Thanks, > Tom > > > ---------- Forwarded message ---------- > From: > Date: Mon, Feb 19, 2018 at 11:06 AM > Subject: New Version Notification for > draft-herbert-ipv6-prefix-address-privacy-00.txt > To: Tom Herbert > > > > A new version of I-D, draft-herbert-ipv6-prefix-address-privacy-00.txt > has been successfully submitted by Tom Herbert and posted to the > IETF repository. > > Name: draft-herbert-ipv6-prefix-address-privacy > Revision: 00 > Title: Privacy in IPv6 Network Prefix Assignment > Document date: 2018-02-20 > Group: Individual Submission > Pages: 17 > URL: > https://www.ietf.org/internet-drafts/draft-herbert-ipv6-pref > ix-address-privacy-00.txt > Status: > https://datatracker.ietf.org/doc/draft-herbert-ipv6-prefix-a > ddress-privacy/ > Htmlized: > https://tools.ietf.org/html/draft-herbert-ipv6-prefix-address-privacy-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-herbert-ipv6-pre > fix-address-privacy-00 > > > Abstract: > This document discusses privacy concerns around network prefix > assignment in IPv6. It evaluates the privacy threat, proposes a set > of ideal criteria for strong privacy, and suggests solutions to > achieve a high degree of privacy in addressing. > > > > > 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 > > _______________________________________________ > 5gangip mailing list > 5gangip@ietf.org > https://www.ietf.org/mailman/listinfo/5gangip > --94eb2c0d29401961b00565b31776 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jon,

Thanks for the reference. I think that both spatial and temporal charac= teristics should be part of strong privacy addresses. Will update the draft= to mention those.

One t= hing that I'm not sure how to quantify yet is the effects of using addr= esses for narrow purposes like a single flow. For instance, if a packet is = seen with some address that might not be useful as a target of attack by tr= ying to connect to the address. No application would be listening on such a= ddresses (although this does make ICMP interesting, like whether there shou= ld be a response to echo request).

Tom


On Feb 20, 2018 2:06 AM, "Jon Cr= owcroft" <jon.crowcro= ft@cl.cam.ac.uk> wrote:
people may already have read this (and its a while ba= ck) but interesting to see the limited but non zero use of privacy v6 addr<= div>https://www.akamai.com/uk/en/multimedia/documents/technical-publication/temporal-and-spatial= -classification-of-active-ipv6-addresses-technical-publicati= on.pdf

On Mon, Feb 19, 2018 at 7:15 PM, Tom He= rbert <tom@quantonium.net> wrote:
Hello,

This draft discusses issue of privacy in IPv6 network prefix
assignment. Specifically the privacy problems of an assigned network
prefix becoming a persistent identifier for devices (e.g. /64
assignment to devices in mobile networks).=C2=A0 The use of
identifier/locator split is suggested as a solution.

Thanks,
Tom


---------- Forwarded message ----------
From:=C2=A0 <internet-drafts@ietf.org>
Date: Mon, Feb 19, 2018 at 11:06 AM
Subject: New Version Notification for
draft-herbert-ipv6-prefix-address-privacy-00.txt
To: Tom Herbert <tom@quantonium.net>



A new version of I-D, draft-herbert-ipv6-prefix-address-privacy-00.txt=
has been successfully submitted by Tom Herbert and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-herbert-ipv6-prefix-add= ress-privacy
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Privacy in IPv6 Network Prefix Ass= ignment
Document date:=C2=A0 2018-02-20
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 17
URL:
https://www.iet= f.org/internet-drafts/draft-herbert-ipv6-prefix-address-privacy-0= 0.txt
Status:
https://datatracker.ietf.= org/doc/draft-herbert-ipv6-prefix-address-privacy/
Htmlized:
https://tools.ietf.org/html/= draft-herbert-ipv6-prefix-address-privacy-00
Htmlized:
https://datatracke= r.ietf.org/doc/html/draft-herbert-ipv6-prefix-address-privacy-00<= /a>


Abstract:
=C2=A0 =C2=A0This document discusses privacy concerns around network prefix=
=C2=A0 =C2=A0assignment in IPv6. It evaluates the privacy threat, proposes = a set
=C2=A0 =C2=A0of ideal criteria for strong privacy, and suggests solutions t= o
=C2=A0 =C2=A0achieve a high degree of privacy in addressing.




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

_______________________________________________
5gangip mailing list
5gangip@ietf.org<= br> https://www.ietf.org/mailman/listinfo/5gangip<= br>


--94eb2c0d29401961b00565b31776-- From nobody Wed Feb 21 05:09:07 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55681200FC for ; Wed, 21 Feb 2018 05:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UioebNsdxnV1 for ; Wed, 21 Feb 2018 05:09:00 -0800 (PST) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58D5112025C for ; Wed, 21 Feb 2018 05:09:00 -0800 (PST) Received: by mail-wr0-x231.google.com with SMTP id u49so4294280wrc.10 for ; Wed, 21 Feb 2018 05:09:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wcZBFwxL3qN2XDocKBVCZ8rLaYns65McGWO6o4UGSvk=; b=j6DnPB60fHd1sP6K7IUGpSDFn/qYNEVUf7vt8ifOJmr4Ql2C2Aipm6gAf/yPMpb0RF 4uwSOZmv5qs2qi74bY6U6fcO09eZJSphKdFPkRNJnS5HYmX2xA7ndqlYeyTBOA4V+G1+ k2hQp2QXjeypq5i3OSTFoVc0STaC5ocvxE5zJk99tZvqZcb2fRftRhe+TpYGntptioxH 9/9dN96VZmw7gbAyh4MXKLfXciGl+4MRhluqVM2vEx+DSLKCAZI3pDlXjh8rGowS9YMG QuGsEIgdVw9Uh2KPyz/heAxitTE6+Lit9VVEhiiZiiAvFmOKefEliMtNyeOovwfcvetD tI2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wcZBFwxL3qN2XDocKBVCZ8rLaYns65McGWO6o4UGSvk=; b=lUrDrSx/6Ef0SnsesXFfnjYab5JbUob3Y0ugaVhSZi1LxHBHm3DLVQ+FmAg27mKG0H Gmb8R28GZl0K8Phw4NwQBHkaV/WAMD+LbiArC2bobApsnaEPsCA3/EKxU8cuftxyde1F rsjHgW/qcjxGzDB0RfzI2NoVHD+WRiUxgh8wEz3yszJ8dtIVrOhdlZTps0F3KlGXTHHu Su9XAcG/AXg44tQ8tqtZ9AV3QZiFhTNVzzcbbXTcxU4m2HHvZItFXEgCYFtIodyQQqb+ Fyztjhyg57cnd018SOguGM7Mqc2biQoDk02AKiZ0j5L3TXZAgURKohE4NMlHUiYBVoRO P7UQ== X-Gm-Message-State: APf1xPB8XB4CJlZoXKvbsJ9HuuCN6g2c0CwPN7eVjF73uhagxK+5hSY4 I8s0/LelRpYYkyBgCFtv+qGUQNYPvcwn44A3DFGbNQ== X-Google-Smtp-Source: AH8x224FAsrtLm5H/L8vY8wDGp/skV3xr87hDh7FNUr24CxjAj0uq2z07UQkgLGUMAbQnbPHNQdk9coXH6aD0aFZVrI= X-Received: by 10.223.208.132 with SMTP id y4mr2813145wrh.185.1519218538337; Wed, 21 Feb 2018 05:08:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.122.9 with HTTP; Wed, 21 Feb 2018 05:08:36 -0800 (PST) In-Reply-To: References: <151906718318.18731.8986618406430268357.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Wed, 21 Feb 2018 22:08:36 +0900 Message-ID: To: Tom Herbert Cc: int-area@ietf.org, ila@ietf.org, 5GANGIP <5gangip@ietf.org> Content-Type: multipart/alternative; boundary="f4f5e80a11245115a30565b8a1db" Archived-At: Subject: Re: [Int-area] [5gangip] Fwd: New Version Notification for draft-herbert-ipv6-prefix-address-privacy-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 13:09:02 -0000 --f4f5e80a11245115a30565b8a1db Content-Type: text/plain; charset="UTF-8" On Tue, Feb 20, 2018 at 4:15 AM, Tom Herbert wrote: > This draft discusses issue of privacy in IPv6 network prefix > assignment. Specifically the privacy problems of an assigned network > prefix becoming a persistent identifier for devices (e.g. /64 > assignment to devices in mobile networks). The use of > identifier/locator split is suggested as a solution. > The draft should state that like any IP address assignment scheme, the addresses used by the host are visible to the network operator and anyone with access to the network operator logs or power to compel the network operator. Thus, randomizing IP addresses does not protect against large-scale surveillance, it can only protect against tracking by third parties. --f4f5e80a11245115a30565b8a1db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 20, 2018 at 4:15 AM, Tom Herbert <tom@quantonium.net> wrote:
This draft discusses issue of p= rivacy in IPv6 network prefix
assignment. Specifically the privacy problems of an assigned network
prefix becoming a persistent identifier for devices (e.g. /64
assignment to devices in mobile networks).=C2=A0 The use of
identifier/locator split is suggested as a solution.
<= br>
The draft should state that like any IP address assignment sc= heme, the addresses used by the host are visible to the network operator an= d anyone with access to the network operator logs or power to compel the ne= twork operator. Thus, randomizing IP addresses does not protect against lar= ge-scale surveillance, it can only protect against tracking by third partie= s.
--f4f5e80a11245115a30565b8a1db-- From nobody Wed Feb 21 06:55:39 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC51127419; Wed, 21 Feb 2018 06:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynL0Gy1KNImw; Wed, 21 Feb 2018 06:55:35 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11585126DFB; Wed, 21 Feb 2018 06:55:35 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CF1DDAF; Wed, 21 Feb 2018 15:55:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1519224932; bh=xUfRX4Th9SPgm02tXGN7mf1yTPEwlqcDu0dBZ97OrTc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Ufvi1SGt6IOkYh9T3AJZ5ZhvpeOJ6nrcozsCK78/DLuay49Jb0MgP6MJeDM2EhLQH y7+yZC95k3biScCVvu3Dgvg8jnTRMEBbb3HgvO57D8Z35oLefvrieuJpT8JpjKu4JM ++oPMX2JBk7eCdWFcYilNhg6v4rR2I9vABp9ozLg= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CCF4F9F; Wed, 21 Feb 2018 15:55:32 +0100 (CET) Date: Wed, 21 Feb 2018 15:55:32 +0100 (CET) From: Mikael Abrahamsson To: Tom Herbert cc: int-area@ietf.org, ila@ietf.org, 5GANGIP <5gangip@ietf.org> In-Reply-To: Message-ID: References: <151906718318.18731.8986618406430268357.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Int-area] [5gangip] Fwd: New Version Notification for draft-herbert-ipv6-prefix-address-privacy-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 14:55:38 -0000 On Mon, 19 Feb 2018, Tom Herbert wrote: > This draft discusses issue of privacy in IPv6 network prefix assignment. > Specifically the privacy problems of an assigned network prefix becoming > a persistent identifier for devices (e.g. /64 assignment to devices in > mobile networks). The use of identifier/locator split is suggested as a > solution. Current state of available address for a PDN is /64. In most implementations I am aware of, if the PDN is brought down, and then up again, a new /64 will be used. The host can therefore control this part of "privacy", cycle PDN when it feels it's appropriate to get new address space to avoid tracking. I am supportive of this approach and any spatial overlap of multiple PDNs/address space approach, so that connections can be moved over to use the new address, gracefully. I consider anything that gives the host less than /64 worth of addresses a regression from current situation. We can always discuss if /80 is enough etc, but anyhow, it's a regression that should be presented front and center by any proposed change to current state of affairs. I have now read section 6 twice, and I still have no idea how many usable addresses the host has available to itself according to draft-herbert-ipv6-prefix-address-privacy-00. Can you please enlighten me? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Feb 21 07:03:59 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD4D12D7F5 for ; Wed, 21 Feb 2018 07:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJMMYWZcXNTm for ; Wed, 21 Feb 2018 07:03:56 -0800 (PST) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28EA612E05D for ; Wed, 21 Feb 2018 07:03:53 -0800 (PST) Received: by mail-wr0-x22a.google.com with SMTP id l43so5377805wrc.2 for ; Wed, 21 Feb 2018 07:03:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zgOhiSxepvo7hf4+S0NFMShK8bo7gX6VGOpfXYScRpg=; b=rakzvAC0RzRCsW07QGqnwfepC2+cQwt2fMcLeLlHjQACGu6axgIS7V1gMwuWNgGEq5 2kwM4efW7gzR0UiJRYJxcR0CBFOKpOvZ7GNyzQbV8jk/phpIxn2dZEkXCUM6vUNUp6Q1 +3RK1Dk9veabWLXS+b24n6tgMX1ftlLgVmmrYOFSYrGSR/B56+wbnoy4sdhmV0arZ04O gawUaqxhpajUj3RqGBYwQTVCi/Fzp2mBcPWKCazVV3pS0cOzTx8cIHjQlUoKQvHOjP+H YfG9hHIicUMbxX926Lx2nvWeS0Jm5DT7U5AJ3BgNDi0Sf4uRdrW3Bxtx5jVlO00FWJU7 Tlag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zgOhiSxepvo7hf4+S0NFMShK8bo7gX6VGOpfXYScRpg=; b=p7O1BtWuQuZY+VRdwP+2edUi3pe9e92uVRkjeT8SjUCzGjJrQaUNPy9m3C8LyQg6y8 cSruqpiAixolxRzat13EOy2t5gh0XwiVwDKmIq1p21jy0PpJXWv85AfEf94RaVj0Qq6r JxAptZ11kqGoCvMJrRunnm1xDTzMHkHsm5sFnv76Ua1diGc6F4G6BaVnOXR0sOw1j5lc jlAoV8oI03rD/fT6pHkjo7+3xl0vFFvBAs0DNWkP3f2HPTiXq1Jw9/4MM92z5zzp1/G+ Pmz3JwI2gKNiYmAzlzDgB+E3IyHQ1Vbcxh9eeOr5j+6nEK5r7154acszjSMtgxSNOcF7 YEiw== X-Gm-Message-State: APf1xPCjZqRIS4WBCzQPhw/2jx8eMYfscNeSk0+heJ8UYvRy0MWQeP/M 1rdr/kwYPpQaYYWKRUtqpikvfoWVEZ1Uq71lgVNpDg== X-Google-Smtp-Source: AH8x226EZLRJ3lFcF57FFytW2qrmYkh7nOs36SqC1eTr0kyYH3wDGkHfNfCTuMZ+a4S7D4hggJGc8AB48WPT+26aQ28= X-Received: by 10.28.69.214 with SMTP id l83mr2227614wmi.116.1519225431250; Wed, 21 Feb 2018 07:03:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.122.9 with HTTP; Wed, 21 Feb 2018 07:03:30 -0800 (PST) In-Reply-To: References: <151906718318.18731.8986618406430268357.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Thu, 22 Feb 2018 00:03:30 +0900 Message-ID: To: Mikael Abrahamsson Cc: Tom Herbert , ila@ietf.org, int-area@ietf.org, 5GANGIP <5gangip@ietf.org> Content-Type: multipart/alternative; boundary="94eb2c07236e2a73980565ba3c89" Archived-At: Subject: Re: [Int-area] [5gangip] Fwd: New Version Notification for draft-herbert-ipv6-prefix-address-privacy-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 15:03:58 -0000 --94eb2c07236e2a73980565ba3c89 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 21, 2018 at 11:55 PM, Mikael Abrahamsson wrote: > > This draft discusses issue of privacy in IPv6 network prefix assignment. >> Specifically the privacy problems of an assigned network prefix becoming a >> persistent identifier for devices (e.g. /64 assignment to devices in mobile >> networks). The use of identifier/locator split is suggested as a solution. >> > > Current state of available address for a PDN is /64. In most > implementations I am aware of, if the PDN is brought down, and then up > again, a new /64 will be used. The host can therefore control this part of > "privacy", cycle PDN when it feels it's appropriate to get new address > space to avoid tracking. I am supportive of this approach and any spatial > overlap of multiple PDNs/address space approach, so that connections can be > moved over to use the new address, gracefully. > +1 > I consider anything that gives the host less than /64 worth of addresses a > regression from current situation. We can always discuss if /80 is enough > etc, but anyhow, it's a regression that should be presented front and > center by any proposed change to current state of affairs. > +1 --94eb2c07236e2a73980565ba3c89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 21, 2018 at 11:55 PM, Mikael Abrahamsson <swmike@swm.pp.se><= /span> wrote:
This draft discusses issue of privacy in IPv6 network prefix assignment. Sp= ecifically the privacy problems of an assigned network prefix becoming a pe= rsistent identifier for devices (e.g. /64 assignment to devices in mobile n= etworks).=C2=A0 The use of identifier/locator split is suggested as a solut= ion.

Current state of available address for a PDN is /64. In most implementation= s I am aware of, if the PDN is brought down, and then up again, a new /64 w= ill be used. The host can therefore control this part of "privacy"= ;, cycle PDN when it feels it's appropriate to get new address space to= avoid tracking. I am supportive of this approach and any spatial overlap o= f multiple PDNs/address space approach, so that connections can be moved ov= er to use the new address, gracefully.

= +1
=C2=A0
I consider anything= that gives the host less than /64 worth of addresses a regression from cur= rent situation. We can always discuss if /80 is enough etc, but anyhow, it&= #39;s a regression that should be presented front and center by any propose= d change to current state of affairs.

+= 1
--94eb2c07236e2a73980565ba3c89-- From nobody Wed Feb 21 07:24:05 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1AE12D7F5 for ; Wed, 21 Feb 2018 07:23:56 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y65-8YdSYnBA for ; Wed, 21 Feb 2018 07:23:54 -0800 (PST) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0268012D7F6 for ; Wed, 21 Feb 2018 07:23:53 -0800 (PST) Received: by mail-wr0-x235.google.com with SMTP id o76so5549461wrb.7 for ; Wed, 21 Feb 2018 07:23:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XhtwRnDZ9M1c+9FKaTN0dzxioKHOj7vsGw7nZzTGmoE=; b=ZRDg0BUj6lcQW39wGpPaPa36BxWvNZR24fg8jIJ/vo6SBZsRnowkLc3Pd5VupUwtrq Q6lpKP1++/kE1uz964KdsCGGREC5cHp7IqCUj8/HQB61M2A1rt8FqaN8CkccxGE4QZj1 bGMDaQTmCEG0qSnAqV6fS090qgbRpZhJ0UouRypd9j+azff0vBt713h8iQLTQ14mkS41 3dXqkjd5aWDHHgaEr6VCmG6LKNP5as7snRXA73dOzS+8XTxzIIuXoBhX+BbthCQxmn8J dNJGRswN80bJ5uT5/S+tuM1wQnpLWsCH90lU+Cj1/b/WiYvYCWkR/G6QsjR1Vl6ZAu6N byXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XhtwRnDZ9M1c+9FKaTN0dzxioKHOj7vsGw7nZzTGmoE=; b=rG+PXETLNuaC2LWhvofYg+XXG6PE2H7uJ/icG2+0kPXurA1O+q9CPDv6z0g7nVfZoH vt8THQ6eeuCDCmIIQGDpyJaV6FI0+fYaW/r2Jgl7vPO/w2U3KWUsPS3O2GfrtBpaNr+7 Hpxu2rrZgdhuM6qRpZ50Fh0fziAuRRlJBRpi3TYIkFGhLzrGkw8AnPDsGxbA91nNScH0 7lH9wxzV2iq2Jr4fV3hX2qYHo4mheCjw5S2hJ8wGBJNuvoNDNXdoP+bGVEHcLzWuKIPU 14DJeOofLfew0O84MpC7/SOnrzV9NhSWYKUzGF+mac54/+BJCCAu6dH8XtfFz32/vnTT 5eIA== X-Gm-Message-State: APf1xPDyhy6qjQrtm+unbIUP5Oh5Q5F07qbZWPvkvtqCa0VbuL4/FQnA Z7MA+2XGBKWnqb/2b+klQZc7OdbIv3WBmQUFVBHpGw== X-Google-Smtp-Source: AH8x227/BhylORNT2opb61KIQFr2sjiseoQx+qwFGSVw9+cgRsVVciXZ5oNxn7ObhHW5X2QcV2CoiwfAmacK4YhzAqk= X-Received: by 10.223.191.10 with SMTP id p10mr3589462wrh.160.1519226632405; Wed, 21 Feb 2018 07:23:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.142.142 with HTTP; Wed, 21 Feb 2018 07:23:52 -0800 (PST) In-Reply-To: References: <151906718318.18731.8986618406430268357.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Wed, 21 Feb 2018 07:23:52 -0800 Message-ID: To: Lorenzo Colitti Cc: int-area@ietf.org, ila@ietf.org, 5GANGIP <5gangip@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Int-area] [5gangip] Fwd: New Version Notification for draft-herbert-ipv6-prefix-address-privacy-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 15:23:57 -0000 On Wed, Feb 21, 2018 at 5:08 AM, Lorenzo Colitti wrote: > On Tue, Feb 20, 2018 at 4:15 AM, Tom Herbert wrote: >> >> This draft discusses issue of privacy in IPv6 network prefix >> assignment. Specifically the privacy problems of an assigned network >> prefix becoming a persistent identifier for devices (e.g. /64 >> assignment to devices in mobile networks). The use of >> identifier/locator split is suggested as a solution. > > > The draft should state that like any IP address assignment scheme, the > addresses used by the host are visible to the network operator and anyone > with access to the network operator logs or power to compel the network > operator. Thus, randomizing IP addresses does not protect against > large-scale surveillance, it can only protect against tracking by third > parties. Lorenzo, AFAICT, the legal requirements for providers to store and provide logs varies by jurisdication. The EU seems to be pretty far along in specifying this. In 2016 an EU court ruled that IP addresses are personally identifiable information (PII) when combined with other information that can reveal identity. A network provider in it's normal operations will know the identity of nodes to which it assign addresses and so must safeguard the information since it is PII. Providers are required to log addressing mappings (like NAT mappings) and must release individual records per legal request. However, I don't think under these rules providers are compelled to blindly provide all logs to authorities for the purposes of data mining (if someone else knows otherwise please interject here). Tom From nobody Wed Feb 21 07:28:45 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D21127010 for ; Wed, 21 Feb 2018 07:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWfoiQpEvh6P for ; Wed, 21 Feb 2018 07:28:36 -0800 (PST) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CCEE12D810 for ; Wed, 21 Feb 2018 07:28:36 -0800 (PST) Received: by mail-wr0-x234.google.com with SMTP id u49so5583783wrc.10 for ; Wed, 21 Feb 2018 07:28:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=34V5lK5p41McuAYQcjODHPLDvUeV71oFaZfU7Vhqi+0=; b=ecvCBFJywAhitdimvWZWEFeL2MjwaHpRey43ajDxURfH3MwpGId7lAObnorb0gVfvW cKnmd8TLDhpIJNH7sLQBPBtXseWLZ1z3c1W/NGZSY9QMCJQB85aemFDCt1dW1gh0ATRw Omi6OudIKXSgsmsryIF9BCySfVdiWR+kZby7N4hW0z3Az6JsRhIg4U8PpVLV/c5jtrRY 8F0WzEysp6Tf0eEHzycf7bvPVU6jhRytrI4k3m4oPBwEf0kNHwlCKbKKe/w2u4h+CwY/ WMTCV/ww7xDiNs6JukM+m1MJnI7JimVQq4t1OYn9SQFwGg/hFPYIpfpiTPE/vSr/XL68 e+7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=34V5lK5p41McuAYQcjODHPLDvUeV71oFaZfU7Vhqi+0=; b=RPL8fYz1goL0FIy9XdtFlkGeN1eoVggaH+WXG39emgtief+SIjcW+ZuLYJr3gVZAFb WMXpPIWO1Mih6YA7J/LOalFQG2QdRs7MOmulIwxuvviMlSm5t2vt9X9VRK+TjzzeagLd yUxwDrqqTwd33uVQeXipgpD3vFG7/zchUqOZsY0dWJoNx2/ChWb2YPS5d+v9QvHiJYOt 4nkSHna7nFtsv27CUmC8C3WQb4VAQG/b6rGkZLsv79TsCMN4EXmRIEfAQmr9IvsXm6kj OcfLXnhrajox7oHbi7SGYrxO47HyXxyzYvMw8KiPKAc2LZPQXmzGATpkbn70mH/NB+yr 1nmQ== X-Gm-Message-State: APf1xPDMFVQMcntxQIrubK1Tl+3r+zrQlSUcSd28BLWsceiQ85g7pNLx +5/4zFLIY7D3b0C1UJz6DFs5Qj74BR1rAtobUO7YmA== X-Google-Smtp-Source: AH8x226eHRQNuavOpruQdZYR9RB0Mwf7R6iSXxm1ZOjm2OyaEuFTbMFsO0QBluK0mjrGZXkzc2En6j4sG+58TJBU7fI= X-Received: by 10.28.12.75 with SMTP id 72mr2289692wmm.97.1519226914169; Wed, 21 Feb 2018 07:28:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.122.9 with HTTP; Wed, 21 Feb 2018 07:28:13 -0800 (PST) In-Reply-To: References: <151906718318.18731.8986618406430268357.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Thu, 22 Feb 2018 00:28:13 +0900 Message-ID: To: Tom Herbert Cc: int-area@ietf.org, ila@ietf.org, 5GANGIP <5gangip@ietf.org> Content-Type: multipart/alternative; boundary="001a1143be328e05280565ba9443" Archived-At: Subject: Re: [Int-area] [5gangip] Fwd: New Version Notification for draft-herbert-ipv6-prefix-address-privacy-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 15:28:39 -0000 --001a1143be328e05280565ba9443 Content-Type: text/plain; charset="UTF-8" ... while in certain other countries, pervasive monitoring was, er... pervasive. On Thu, Feb 22, 2018 at 12:23 AM, Tom Herbert wrote: > On Wed, Feb 21, 2018 at 5:08 AM, Lorenzo Colitti > wrote: > > On Tue, Feb 20, 2018 at 4:15 AM, Tom Herbert wrote: > >> > >> This draft discusses issue of privacy in IPv6 network prefix > >> assignment. Specifically the privacy problems of an assigned network > >> prefix becoming a persistent identifier for devices (e.g. /64 > >> assignment to devices in mobile networks). The use of > >> identifier/locator split is suggested as a solution. > > > > > > The draft should state that like any IP address assignment scheme, the > > addresses used by the host are visible to the network operator and anyone > > with access to the network operator logs or power to compel the network > > operator. Thus, randomizing IP addresses does not protect against > > large-scale surveillance, it can only protect against tracking by third > > parties. > > Lorenzo, > > AFAICT, the legal requirements for providers to store and provide logs > varies by jurisdication. The EU seems to be pretty far along in > specifying this. In 2016 an EU court ruled that IP addresses are > personally identifiable information (PII) when combined with other > information that can reveal identity. A network provider in it's > normal operations will know the identity of nodes to which it assign > addresses and so must safeguard the information since it is PII. > Providers are required to log addressing mappings (like NAT mappings) > and must release individual records per legal request. However, I > don't think under these rules providers are compelled to blindly > provide all logs to authorities for the purposes of data mining (if > someone else knows otherwise please interject here). > > Tom > --001a1143be328e05280565ba9443 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
... while in certain other countries, pervasive monitoring= was, er... pervasive.

On Thu, Feb 22, 2018 at 12:23 AM, Tom Herbert = <tom@quantonium.= net> wrote:
On Wed, Feb 21, 2018 at 5:08 AM, Lorenzo Colitti &= lt;lorenzo@google.com> wrote:<= br> > On Tue, Feb 20, 2018 at 4:15 AM, Tom Herbert <tom@quantonium.net> wrote:
>>
>> This draft discusses issue of privacy in IPv6 network prefix
>> assignment. Specifically the privacy problems of an assigned netwo= rk
>> prefix becoming a persistent identifier for devices (e.g. /64
>> assignment to devices in mobile networks).=C2=A0 The use of
>> identifier/locator split is suggested as a solution.
>
>
> The draft should state that like any IP address assignment scheme, the=
> addresses used by the host are visible to the network operator and any= one
> with access to the network operator logs or power to compel the networ= k
> operator. Thus, randomizing IP addresses does not protect against
> large-scale surveillance, it can only protect against tracking by thir= d
> parties.

Lorenzo,

AFAICT, the legal requirements for providers to store and provide logs
varies by jurisdication. The EU seems to be pretty far along in
specifying this. In 2016 an EU court ruled that IP addresses are
personally identifiable information (PII) when combined with other
information that can reveal identity. A network provider in it's
normal operations will know the identity of nodes to which it assign
addresses and so must safeguard the information since it is PII.
Providers are required to log addressing mappings (like NAT mappings)
and must release individual records per legal request. However, I
don't think under these rules providers are compelled to blindly
provide all logs to authorities for the purposes of data mining (if
someone else knows otherwise please interject here).

Tom

--001a1143be328e05280565ba9443-- From nobody Wed Feb 21 07:31:10 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA9312D7E5; Wed, 21 Feb 2018 07:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-WY2HZQuQmk; Wed, 21 Feb 2018 07:30:58 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15CBF12D810; Wed, 21 Feb 2018 07:30:58 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1B3DCB0; Wed, 21 Feb 2018 16:30:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1519227056; bh=zu7bwQSHZxj7a/Q9fqq+vYSa1jCXBTian1HkicOuhNU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=rxyBZcD6UlR/dcXqzbC5eNMRvEyonHEMvLlDShZhl3IuiUHewPFEpPeq3NbK69S8B HaXwH3YNcCj+O/uw8Px89w3pAYr53qh+zb64e404TN1tsHyanGcApzKOpi9orR8utQ ivABAArVLxCxba2D8pS8b3AvnRH0NThOAuNysUlU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 187699F; Wed, 21 Feb 2018 16:30:56 +0100 (CET) Date: Wed, 21 Feb 2018 16:30:56 +0100 (CET) From: Mikael Abrahamsson To: Tom Herbert cc: Lorenzo Colitti , ila@ietf.org, int-area@ietf.org, 5GANGIP <5gangip@ietf.org> In-Reply-To: Message-ID: References: <151906718318.18731.8986618406430268357.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Int-area] [5gangip] Fwd: New Version Notification for draft-herbert-ipv6-prefix-address-privacy-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 15:30:59 -0000 On Wed, 21 Feb 2018, Tom Herbert wrote: > On Wed, Feb 21, 2018 at 5:08 AM, Lorenzo Colitti wrote: >> >> The draft should state that like any IP address assignment scheme, the >> addresses used by the host are visible to the network operator and anyone >> with access to the network operator logs or power to compel the network >> operator. Thus, randomizing IP addresses does not protect against >> large-scale surveillance, it can only protect against tracking by third >> parties. > > AFAICT, the legal requirements for providers to store and provide logs > varies by jurisdication. The EU seems to be pretty far along in > specifying this. In 2016 an EU court ruled that IP addresses are > personally identifiable information (PII) when combined with other > information that can reveal identity. A network provider in it's > normal operations will know the identity of nodes to which it assign > addresses and so must safeguard the information since it is PII. > Providers are required to log addressing mappings (like NAT mappings) > and must release individual records per legal request. However, I > don't think under these rules providers are compelled to blindly > provide all logs to authorities for the purposes of data mining (if > someone else knows otherwise please interject here). I think you can safely assume that there are juristictions in the world where the authorities have real-time and historical full access to anything the operator has logged. However, there is no technical solution to this human problem, so I don't see it as anything we can solve. Apart from that, it seems to me that you're both saying the same thing. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Feb 21 07:47:38 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B494912D7F9 for ; Wed, 21 Feb 2018 07:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ws6OB9x_FlXt for ; Wed, 21 Feb 2018 07:47:35 -0800 (PST) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BDF512D7F5 for ; Wed, 21 Feb 2018 07:47:35 -0800 (PST) Received: by mail-wr0-x235.google.com with SMTP id l43so5789219wrc.2 for ; Wed, 21 Feb 2018 07:47:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bel8Ra0BY/PJWs+MpX3Lhv7Q8dnDZ2QSJsm0KphmXzg=; b=DUEr+4TrwQSen4MXT6T8ZtPEaaszh04V+E+QpGPNFmGhtwtE5TEWIvv60BoQM/IHyT 1QpUxbVlPJ/Ic4H9N8y6ptPSBQeE0A1UW+vpXDkYm9WEPOsYLwry7h9swtBoRdU6C3CG /c1oOU/lMUF2Ksv1DK4VztMkQDsyoLerHg72HA8bd+DhJaieXJw/Zsuu8D2SguC6zny7 AMLCdRuIqISftaz7a6JL7qokFDBVqLXfrlZu2BF/Wu/54PNhJ1Ndfmj3cb09UZ1cPEtN Gp8lJOwZ+kp15bhcJYNRhEGyBV2iwLqWPG0QOTFPX3LBv9y+E0FpHfiUkpDrhulh0dKF +KXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bel8Ra0BY/PJWs+MpX3Lhv7Q8dnDZ2QSJsm0KphmXzg=; b=DPv/lQ5UNWAE/7Q23nj7roOjH8lS8cIp+AqJAHT+b0bqCqVFa+EpxSNhrmwsr28QjH jfNyRIaAtgX6PntGNH6ZiNA0ll/nkLBivWqQVR8nN3Yayi9Zw/ERfj267qNEqdnNp7eU 91N3iP/aFSRx/+1MJNdG9Sv5/xkqFK1hgFvIU56TAJbzRDwpZzRROb4g17gw+8ofTSh4 pntu8BkGKHF8Sue2OVOUFpAeCZMuOpBRRLqxea9HUCUDFtp7qvDBcLKc92kYF45w49gP c6HrHfPHqm4h0l2RzazOwDaf2FWqTNaTN37TIrseLeF0dT0wCQaPjw9qpUkQK+eAPER0 rK4A== X-Gm-Message-State: APf1xPC6vBsvqAu4WkIJIixRfBtXMb8CLkFwN6u6Zpwxa88DBgMhA1vr vP7j6A3TaRTFBKztcKl4X//dIuOKUY4F+7DYHONc5Q== X-Google-Smtp-Source: AH8x22604Sl0kOsY8JGZOsnP+rj/SkdlhKIm7Hw0BTOjbipP8NCeT2Ux/Kc/nb5gno1qy8c/f6Edul6EO7wvWZW8maM= X-Received: by 10.223.143.101 with SMTP id p92mr3454238wrb.241.1519228053515; Wed, 21 Feb 2018 07:47:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.156.210 with HTTP; Wed, 21 Feb 2018 07:47:32 -0800 (PST) In-Reply-To: References: <151906718318.18731.8986618406430268357.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Wed, 21 Feb 2018 07:47:32 -0800 Message-ID: To: Mikael Abrahamsson Cc: int-area@ietf.org, ila@ietf.org, 5GANGIP <5gangip@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Int-area] [5gangip] Fwd: New Version Notification for draft-herbert-ipv6-prefix-address-privacy-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 15:47:37 -0000 On Wed, Feb 21, 2018 at 6:55 AM, Mikael Abrahamsson wrote: > On Mon, 19 Feb 2018, Tom Herbert wrote: > >> This draft discusses issue of privacy in IPv6 network prefix assignment. >> Specifically the privacy problems of an assigned network prefix becoming a >> persistent identifier for devices (e.g. /64 assignment to devices in mobile >> networks). The use of identifier/locator split is suggested as a solution. > > > Current state of available address for a PDN is /64. In most implementations > I am aware of, if the PDN is brought down, and then up again, a new /64 will > be used. The host can therefore control this part of "privacy", cycle PDN > when it feels it's appropriate to get new address space to avoid tracking. I > am supportive of this approach and any spatial overlap of multiple > PDNs/address space approach, so that connections can be moved over to use > the new address, gracefully. > > I consider anything that gives the host less than /64 worth of addresses a > regression from current situation. We can always discuss if /80 is enough > etc, but anyhow, it's a regression that should be presented front and center > by any proposed change to current state of affairs. > > I have now read section 6 twice, and I still have no idea how many usable > addresses the host has available to itself according to > draft-herbert-ipv6-prefix-address-privacy-00. > > Can you please enlighten me? > Mikael, As mentioned in section 6, addresses contain no hierachy beyond the provider prefix so the space over which addresses are assign can be flat large space (/32, /48, etc). The goal is that from any outside observer all addresses seem to be randomly chosen from the space with no means to create correlations. Host are assigned addresses from the space. The goal is that all addresses appear to be randomly assigned in that space. Conceptually, a host could request assignment for inidivual millions or billions of addresses, but that won't scale. The alternative suggested is to assign addresses in blocks using hidden aggregation as described in section 6.2.2.2. Blocks would contain multiple addresses (could be thousands, millions, etc.). Tom From nobody Wed Feb 21 08:03:50 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4826124B17; Wed, 21 Feb 2018 08:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFrc4TipX5Tp; Wed, 21 Feb 2018 08:03:38 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3A312D7F8; Wed, 21 Feb 2018 08:03:37 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B68A7B0; Wed, 21 Feb 2018 17:03:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1519229014; bh=WOr44/8i/0sBWY60qNE6xBtLDLTnucoUcKGU3j4Ay5M=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=haFvmaSiLg3c0SbvWw8porb9+Z8vxDJpL96J0yBsJs/Hz52VQwsRvJD/y1NbP1GKb gqoDTdQ6k6+i/GGBk+gQsLdOIyzafT+lPCmpPU1e46fGP/NiV45MY60JUrtPMDCSZA 4lubpovSZbFcvNx8je+uUnOfwN0ULSlBMxeTWuOM= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B302F9F; Wed, 21 Feb 2018 17:03:34 +0100 (CET) Date: Wed, 21 Feb 2018 17:03:34 +0100 (CET) From: Mikael Abrahamsson To: Tom Herbert cc: int-area@ietf.org, ila@ietf.org, 5GANGIP <5gangip@ietf.org> In-Reply-To: Message-ID: References: <151906718318.18731.8986618406430268357.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Int-area] [5gangip] Fwd: New Version Notification for draft-herbert-ipv6-prefix-address-privacy-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 16:03:41 -0000 On Wed, 21 Feb 2018, Tom Herbert wrote: > Host are assigned addresses from the space. The goal is that all > addresses appear to be randomly assigned in that space. Conceptually, a > host could request assignment for inidivual millions or billions of > addresses, but that won't scale. The alternative suggested is to assign > addresses in blocks using hidden aggregation as described in section > 6.2.2.2. Blocks would contain multiple addresses (could be thousands, > millions, etc.). This means the host still needs to cycle these blocks over time to maintain privacy. Does the scaling still support a host having hundreds of these blocks at any given time? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Feb 21 17:52:03 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079A312E053 for ; Wed, 21 Feb 2018 17:52:01 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gxblzupQBPx for ; Wed, 21 Feb 2018 17:51:59 -0800 (PST) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 653F312E04B for ; Wed, 21 Feb 2018 17:51:59 -0800 (PST) Received: by mail-wr0-x22c.google.com with SMTP id z12so8980008wrg.4 for ; Wed, 21 Feb 2018 17:51:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NzO0JjyQr4/fVq5DE+3DBGqB8xQxOgnSC5oMyf7zzC0=; b=0wVA9cnE84ulZJVyF/JOfyzANfbWoamEY7+QTut/OYUnLmcpY5DNcbb0E8BACW8LCi aHXEwtnid/4elTrCmdp8El3bYjhezrrZYaqX8KhSbXLE/BWBN7oyBNr1D3gRx7Ai1+Ks ylHuFScfgRyp78+eg6ljioro97ZbdOw7Rq7S5SvUcaNcSZ93RnfX9UOCsVO8kGeCBTp2 31kAsJlnh1w/OWa+mqZu66KOpKMkTaubIWLGQtJqNg7LytOxom3R5/afVBzo3wrZ0D3M xHtI+MZxDyd/2C5jUoJGHQfUv70uvYONJH7+Nyj3WhQ+1Su0aCFy4/VBVYPAWeO0z3Hb FtMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NzO0JjyQr4/fVq5DE+3DBGqB8xQxOgnSC5oMyf7zzC0=; b=KhSaLdXBeQxAlZm834AsiyKKplQRiccAouovfPMtz8JLTtAaxdkXK6kPAGeBq8Q482 7yPOnkwHiMNfATq9phm9gRe6fTo4Aj6/Wai6nF0uU2pyMZeCyRFohE7EJgrutAkI6qlJ kF2keF1rhFKMjUivMvFr0KiygLRv7QtAk2mGLPPZMD8lc04EHZ6HKhs/sMHmrbqZH8jk 8L/5KUN8m9qyWTJO91Z6V38onWoj77+FPaM8YhSn0rzBlx58dfDS+krEiSnjreWV/vNl QiRAkqmgO/Tmu3rrXA+Uo2MbuKyLr+Nb3f2F/TLMjmEbOoG6iKsXqvXfghS1kQho9xLz HymQ== X-Gm-Message-State: APf1xPBFmjd3gFIOPP+DkuvoxXgGzUssqH59J4RiwFCtebFyzAd99dD5 nURn+qvBQhdWOuMEJ9m9RnC8UT7lqwDE2HmvmlgIlA== X-Google-Smtp-Source: AH8x227MEoUvjtZJcXwa+Qz9aXuzk0StCyGeVAOvge9GwstXKhVZSgUveiEbgGIlEaAMgUFuRcMhtYdlB7JA+r5sIDc= X-Received: by 10.223.165.67 with SMTP id j3mr3114015wrb.111.1519264317846; Wed, 21 Feb 2018 17:51:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.135.74 with HTTP; Wed, 21 Feb 2018 17:51:57 -0800 (PST) In-Reply-To: References: <151906718318.18731.8986618406430268357.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Wed, 21 Feb 2018 17:51:57 -0800 Message-ID: To: Mikael Abrahamsson Cc: int-area@ietf.org, ila@ietf.org, 5GANGIP <5gangip@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Int-area] [5gangip] Fwd: New Version Notification for draft-herbert-ipv6-prefix-address-privacy-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 01:52:01 -0000 On Wed, Feb 21, 2018 at 8:03 AM, Mikael Abrahamsson wrote: > On Wed, 21 Feb 2018, Tom Herbert wrote: > >> Host are assigned addresses from the space. The goal is that all addresses >> appear to be randomly assigned in that space. Conceptually, a host could >> request assignment for inidivual millions or billions of addresses, but that >> won't scale. The alternative suggested is to assign addresses in blocks >> using hidden aggregation as described in section 6.2.2.2. Blocks would >> contain multiple addresses (could be thousands, millions, etc.). > > > This means the host still needs to cycle these blocks over time to maintain > privacy. Does the scaling still support a host having hundreds of these > blocks at any given time? > Mikael, Yes, blocks are a finite resource and so would have to have TTL and be reclaimed. Also, if keys are involved in address creation they would need expected management and key rotation. Address space should be big enough to make long TTLs. The hidden aggregation method is intended to make scaling possible. Each assigned block results in on entry in mapping system so total amount of state is num_hosts*num_blocks per host. e.g. in a network of 10M nodes with 100 blocks per host that's 1B entries in the mapping system-- should be able to scale that. If block size is 2^16 then if every address is in the mapping system it's 6.5e11-- harder to scale. Aggregation is needed keep network state reasonable for scaling, but aggregation that is visible to the outside world exposes information about network internals of network and potentially PII as discussed in the draft. Tom > > -- > Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Feb 21 19:38:47 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354C81204DA for ; Wed, 21 Feb 2018 19:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3yK4voAwAcb for ; Wed, 21 Feb 2018 19:38:40 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45FFA124207 for ; Wed, 21 Feb 2018 19:38:38 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id z81so1181463wmb.4 for ; Wed, 21 Feb 2018 19:38:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=skfEBfH4SIX8jLTOc2ONPKqttiKVLJ4gAaRZ3t+GdBE=; b=uY88uCVGUviAa9C1i9tUlv/q9SAU9i79LY+lOdlzfU/j60qalGkqwvAzAbMNdB3oto bn21AbQ3P5GyWy9m9FRsSFV4+SJM8EdRfBdSRcGVZgdfySRirgGAGSdl9OS7wx8mrTxx bk8AQvTkp18YymISAUDZq66rZsVSJCqRuFRHt2c3re+i/2PYejjMs6xHpc7g6d/4pcq/ jcQlcoz0AMk/NGIRLDjMuawNem1CUYVXLCKUYTXYv6chZrPYJL+/F+qU+BdVBQ7krl/U yn1fn5Kv07Y2wGcf8n+Jq+P55d+NH2DUpvXXm0O8JEe0Yx5npg2M3Y0ejD8scDI6QDmU j88g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=skfEBfH4SIX8jLTOc2ONPKqttiKVLJ4gAaRZ3t+GdBE=; b=kdLJRF+UXE/8j6jeNx/wb+h0amC29TMGv4hSa3x8CV4mX9anXg9KB0QyzpZ0ggKI2s ZSM/UfCqN4hDNnYx2+yw9l1vkhm8XnFriJa15J+hYK+Bv0wH57dop88BpyAx4AFKXprD lC9ca8QJ8CQf1e9r3g/MCXYkPZCeIwYYg/pvi0eGid2pDrAzVLzjOozX/aGNuONSyIjH Gse2yKnzbZCBnlGsk8H5bw/9IpMd/b0PW1L0wnYGCpjLrBfzoOlEpr5Gc5NIHTRiqtw4 nnd1MeKJBCahA99ZH9kfgQWUpaEuB+Esf3lWM2VLF5JFZ3r5oUiACd7hQ5RbDJcNbjx0 3WCw== X-Gm-Message-State: APf1xPAgDStepRmuZJMFNywUIIA75Th1hQglI+sNGlhwBUQiok2Zye8r rrYtX4kW5/SJe6J+hjgPMlqS1S9Nu5eQLmdYK9yvcQ== X-Google-Smtp-Source: AH8x226JA2OctcNoJjQ+kde4geuequj9ADZD3n42I6RRZvDLzKrf58JN0jMGSVYFvdbj2RzBnb9NZy5HwsM/aX54M5Q= X-Received: by 10.28.69.131 with SMTP id l3mr3479612wmi.155.1519270716436; Wed, 21 Feb 2018 19:38:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.122.9 with HTTP; Wed, 21 Feb 2018 19:38:15 -0800 (PST) In-Reply-To: References: <151906718318.18731.8986618406430268357.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Thu, 22 Feb 2018 12:38:15 +0900 Message-ID: To: Tom Herbert Cc: Mikael Abrahamsson , ila@ietf.org, int-area@ietf.org, 5GANGIP <5gangip@ietf.org> Content-Type: multipart/alternative; boundary="001a114d24205f92810565c4c758" Archived-At: Subject: Re: [Int-area] [5gangip] Fwd: New Version Notification for draft-herbert-ipv6-prefix-address-privacy-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 03:38:41 -0000 --001a114d24205f92810565c4c758 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 22, 2018 at 10:51 AM, Tom Herbert wrote: > The hidden aggregation method is intended to make scaling possible. > Each assigned block results in on entry in mapping system so total > amount of state is num_hosts*num_blocks per host. e.g. in a network of > 10M nodes with 100 blocks per host that's 1B entries in the mapping > system-- should be able to scale that. I have a fundamental problem with the assertion "should be able to scale to 1B mapping entries" given that a) current routing hardware capabilities are three orders of magnitude away from that, and b) anyone on the Internet can mount a state exhaustion attack on the mapping system simply by originating a packet to any IPv6 address in the domain. Personally I don't think this work should progress until we have line of sight to a system that can actually do that. --001a114d24205f92810565c4c758 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 22, 2018 at 10:51 AM, Tom Herbert <tom@quantonium.net> wrote:
The hidden aggregation method = is intended to make scaling possible.
Each assigned block results in on entry in mapping system so total
amount of state is num_hosts*num_blocks per host. e.g. in a network of
10M nodes with 100 blocks per host that's 1B entries in the mapping
system-- should be able to scale that.

I ha= ve a fundamental problem with the assertion "should be able to scale t= o 1B mapping entries" given that a) current routing hardware capabilit= ies are three orders of magnitude away from that, and b) anyone on the Inte= rnet can mount a state exhaustion attack on the mapping system simply by or= iginating a packet to any IPv6 address in the domain.

<= div>Personally I don't think this work should progress until we have li= ne of sight to a system that can actually do that.
--001a114d24205f92810565c4c758-- From nobody Wed Feb 21 20:12:53 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25DCD12E8CA for ; Wed, 21 Feb 2018 20:12:52 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mcr-cbAFlHkF for ; Wed, 21 Feb 2018 20:12:50 -0800 (PST) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9555C124B0A for ; Wed, 21 Feb 2018 20:12:50 -0800 (PST) Received: by mail-wr0-x241.google.com with SMTP id k9so9158125wre.9 for ; Wed, 21 Feb 2018 20:12:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=D/uI1n+ynl+jWVY+0Z25teeeK1RHHF9SgAksNpPoa6Y=; b=bmsYZQ9UHaHVw4otT6XcIGYPsOXTQwpyPRfIRZSSfy7VvWilRajN4ZwXc0bPB0Pzwm Ldqd8PYbsYIZ37oBRvofgly6UatI/1M8Puut03PQr55KhISYxCWvhWWIvMua2FgQMwkk Yl927RUizuGRXtDQe5+nAnGSxHw70MRtIM4IBAmUD/m+Hx7V8Wij1NHfBREnTzSFG+NT Svlku6dPCZH5gwYyH1NmpYz5vcRDwumFx4Zl3FLHFbYe/qJou6blNJnGK6SkQKDk9JeT 6O8iB4a5oXEHgD5S9+XPcs0h7Kt/x9RXzrVzKdQ7b5Azh1cw4MWQ2qvs2m2nZb1aNQmc YXgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=D/uI1n+ynl+jWVY+0Z25teeeK1RHHF9SgAksNpPoa6Y=; b=mnaYm/4SZtx8I3A6Jyo33Yb5Eu6gpTZLzwtkEUaQSvYtJXThr831KyPgVpXtexLxoo UMJCUgv0rKprltTLnZHcXRQqCZdJfvb8RmuIVV7ZtErvcPnpR08kpvbeJNULWxRT0Qls HgQIEGmRr0sxYoft2Iqo9EGEPs7t14c0rg5enA6v8ZNe5veNDN7/Fx9a0G5/FulFr2cR mXRFD4zPrkey3NiDUaSy9gZzxOct4yecg8M6++v3dn4R4u5amFu/VNo84tmdPxGtl63G YCX6PGkE81+7N4LR4YyBm82XcUC2Yeg83eoFwSOzdEAWz277Gd1Gf1sqFJX9htso7d7M P8ng== X-Gm-Message-State: APf1xPAAShKYx0H8f+bjLH56N2567UWXBILeCXHHlwb+zduUwKNydCfM 3qS1elUQdru80XZl3e+XVoEdYtm2o5RA39/JAKnWvg== X-Google-Smtp-Source: AH8x227P8FTUmiskXE5j+jfd53peSiLgnmY618EDUMw1aGKWwr7V17YctCDxu42d8QbNPv/z2MVjUJI8dS3jhtbkAMo= X-Received: by 10.223.131.133 with SMTP id 5mr4469372wre.153.1519272769070; Wed, 21 Feb 2018 20:12:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.156.210 with HTTP; Wed, 21 Feb 2018 20:12:48 -0800 (PST) In-Reply-To: References: <151906718318.18731.8986618406430268357.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Wed, 21 Feb 2018 20:12:48 -0800 Message-ID: To: Lorenzo Colitti Cc: Mikael Abrahamsson , ila@ietf.org, int-area@ietf.org, 5GANGIP <5gangip@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Int-area] [5gangip] Fwd: New Version Notification for draft-herbert-ipv6-prefix-address-privacy-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 04:12:52 -0000 On Wed, Feb 21, 2018 at 7:38 PM, Lorenzo Colitti wrote: > On Thu, Feb 22, 2018 at 10:51 AM, Tom Herbert wrote: >> >> The hidden aggregation method is intended to make scaling possible. >> Each assigned block results in on entry in mapping system so total >> amount of state is num_hosts*num_blocks per host. e.g. in a network of >> 10M nodes with 100 blocks per host that's 1B entries in the mapping >> system-- should be able to scale that. > > > I have a fundamental problem with the assertion "should be able to scale to > 1B mapping entries" given that a) current routing hardware capabilities are > three orders of magnitude away from that, and b) anyone on the Internet can > mount a state exhaustion attack on the mapping system simply by originating > a packet to any IPv6 address in the domain. > The complete mapping system is not required to be stored in a single device it is sharded. So if a single device hold 10M entries, then 100 devices are required with some multiplier needed for redundancy and load. The numbers are not out of line with numbers of routers that are deployed in large provider networks today. However, scaling into the future especially with vast numbers of IoT devices, like the 1T devices projection, will require more work (but even without this work on scaling is still needed). > Personally I don't think this work should progress until we have line of > sight to a system that can actually do that. I would think that a major part of the work is to implement a mapping system and identifier/locator protocol and to demonstate the scaling properties. This is work currently in progress. Tom From nobody Wed Feb 21 20:13:36 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FE2124B0A; Wed, 21 Feb 2018 20:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpXKuKlV5KX8; Wed, 21 Feb 2018 20:13:15 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1FC012E8D7; Wed, 21 Feb 2018 20:13:14 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id z14so1611249pfe.10; Wed, 21 Feb 2018 20:13:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=K/Bj8d/xNlWROAhgBlYd1UrKk4TGvXPiLgOSLdsPa1A=; b=W6QluSaKNN792gObA7abtN4t90KPR16Es+L+IF8btd/gZtv059AvseSDqdXbz0ZrTS aPM6ARPjpkKFsqO5bErVZgSowEkWMRUJq+SxSbvVNEyd6sMm6plOMspqBmvz8lbhLUV1 a/Yrxj5qk31JMXtMqPmtIb9XxIvsJkhqikl2e0h5ZBguiH9cbWxK+4BEDkdj7AMpif7e n5au1C9wRaXXGuR0f6g2j5qqNs5i0upKkT4srFgxo13ct8sycA2Lp7DV6xKz4vvU9IrF sJpl4HGnEl36TEGKxXc1klvLAY9Ic1QV33mNH8wNmYODXKRkZJd8aKZV54avMqBGx3Vj aObg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=K/Bj8d/xNlWROAhgBlYd1UrKk4TGvXPiLgOSLdsPa1A=; b=DzKlYjlGlp92AiMkfupbCBT8CWEqDUdJ7Dy+g61Ev3NEi+/gpJ5uSk6G81DZC1eyDg hk5lu3+rh5bAP1uxIlbC/c0BGmHFvrtmVoiU6VTI2ZJqzN8xikEQnuFR9LubAQblXf7B 14/cAoXjMJebJSLN9N+5t9jxHYI8JNFz3GVkbbytmpq0ciiOtMLSmiJRT4hkY3BSMAXn gnnHHgvOBElNbwXUJjHW+vGkcuMXEAjBjl4o53BTaWDzoU7QSZ+MFsUH/mpWxHALpOyW /l3RZK/4+0lpaIYjGO91FxAcefCwaVZLK1qGcZEQ2BIegnr4Yx/8T8LMwjkYgtZVq9JS 6APw== X-Gm-Message-State: APf1xPDvgbBYqUeOZXx3G4xUQaxtLxjliq6DMDZYIjDIzv2ZzaS3QyMp ekEz1dCehrRgd3ZaU3YsbuU= X-Google-Smtp-Source: AH8x224+Z9x7/oIZ5F4FSi9nvso2x/N8skf2/hytLrWe1191aySHrlzO+Z8rozziD8Gj95LzsxiIoA== X-Received: by 10.98.18.70 with SMTP id a67mr5520946pfj.213.1519272794086; Wed, 21 Feb 2018 20:13:14 -0800 (PST) Received: from dino-macbook.wp.comcast.net (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by smtp.gmail.com with ESMTPSA id 12sm73508094pfr.147.2018.02.21.20.13.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Feb 2018 20:13:12 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Dino Farinacci In-Reply-To: Date: Wed, 21 Feb 2018 20:12:57 -0800 Cc: Tom Herbert , int-area@ietf.org, ila@ietf.org, 5GANGIP <5gangip@ietf.org>, Mikael Abrahamsson Content-Transfer-Encoding: quoted-printable Message-Id: <71A0B6CB-ADF2-4D76-9DA5-6BC350AA75A8@gmail.com> References: <151906718318.18731.8986618406430268357.idtracker@ietfa.amsl.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Int-area] [5gangip] Fwd: New Version Notification for draft-herbert-ipv6-prefix-address-privacy-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 04:13:24 -0000 The Internet works today with billions of nodes connected. Why is that? = Because not all of them are in single routing hardware. I realize = aggregation allows for billions of individual addresses, but let=E2=80=99s= compare this to DNS where an entry equals an individual address. Maybe =E2=80=9Cmapping entries globally=E2=80=9D does not equal = =E2=80=9Cmapping entries in a given table=E2=80=9D. Dino > On Feb 21, 2018, at 7:38 PM, Lorenzo Colitti = wrote: >=20 > On Thu, Feb 22, 2018 at 10:51 AM, Tom Herbert = wrote: > The hidden aggregation method is intended to make scaling possible. > Each assigned block results in on entry in mapping system so total > amount of state is num_hosts*num_blocks per host. e.g. in a network of > 10M nodes with 100 blocks per host that's 1B entries in the mapping > system-- should be able to scale that. >=20 > I have a fundamental problem with the assertion "should be able to = scale to 1B mapping entries" given that a) current routing hardware = capabilities are three orders of magnitude away from that, and b) anyone = on the Internet can mount a state exhaustion attack on the mapping = system simply by originating a packet to any IPv6 address in the domain. >=20 > Personally I don't think this work should progress until we have line = of sight to a system that can actually do that. > _______________________________________________ > 5gangip mailing list > 5gangip@ietf.org > https://www.ietf.org/mailman/listinfo/5gangip From nobody Thu Feb 22 04:33:13 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7363712EA97 for ; Thu, 22 Feb 2018 04:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 U4gUGBZZpHb3 for ; Thu, 22 Feb 2018 04:33:09 -0800 (PST) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81FB412EA94 for ; Thu, 22 Feb 2018 04:33:08 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w1MCX7UL027291 for ; Thu, 22 Feb 2018 13:33:07 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 688B6202DB5 for ; Thu, 22 Feb 2018 13:33:07 +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 558E3202B46 for ; Thu, 22 Feb 2018 13:33:07 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1MCX7S8009357 for ; Thu, 22 Feb 2018 13:33:07 +0100 To: int-area@ietf.org References: <8B2B1A59-7DDC-42D2-A660-A954BEB0368A@cisco.com> From: Alexandre Petrescu Message-ID: Date: Thu, 22 Feb 2018 13:33:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <8B2B1A59-7DDC-42D2-A660-A954BEB0368A@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Int-area] Hackathon about PvD at IETF-101 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 12:33:11 -0000 Rather .org right? https://www.neat-project.org/ Le 20/02/2018 à 11:05, Eric Vyncke (evyncke) a écrit : > If you want to test your PvD (draft-ietf-intarea-provisioning-domains) > implementation, or help with the integration of PvD into NEAT project > (EU-funded H2020 ) then you are welcome to > participate to the free hackathon on the WE before the IETF-101. > > Open source code: https://github.com/IPv6-mPvD (2 daemons sending RA + > Linux Kernel to handle PvD) > > More information about the hackathon: > > > Signup: https://www.ietf.org/registration/ietf101/hackathonregistration.py > >             More > information: https://ietf.org/how/runningcode/hackathons/101-hackathon/ > >             Keep up to date by subscribing to: > >             https://www.ietf.org/mailman/listinfo/hackathon > > -éric, -pierre and -tom > > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > From nobody Thu Feb 22 05:52:53 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D6212EACC for ; Thu, 22 Feb 2018 05:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzZsd7agApcf for ; Thu, 22 Feb 2018 05:52:50 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D50B12EACB for ; Thu, 22 Feb 2018 05:52:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2066; q=dns/txt; s=iport; t=1519307570; x=1520517170; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Z/Pb8BQVHNUwQ3HoeJdjlFFeRUGFaWOMvjx8Sv3u6XA=; b=QF28vi1+eVedYyesiFVGEatH4eSjXfwiC1w5qdip28HfHhnjeedguQt5 sw4vHjgobreiR5jWsqQTSFMzLs3saJViNLXPsjiW6WOBXm9wX8h7s3bVC +7jHvxvD2CuIbR06IYUoFO9TkSZii32spJaLhGU09CA4p6Fy736Spf6Py 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAQDtyY5a/4UNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNPZnAoCoNeiiWNeIMYiAGOTYIWChgLhEJPAhqCEVQYAQIBAQE?= =?us-ascii?q?BAQECayiFJAIEAQEhETobAgEIGgImAgICHwYLFRACBAESigsDFRCqUoInhQCCN?= =?us-ascii?q?g2BMoITAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4QCgieBV4FnKYMFgUmBI0Q?= =?us-ascii?q?BAYIIgwAxgjQFpAo1CQKIJohbhQuURI4MSIkpAhEZAYE7AR85gVFwFToqAYIIA?= =?us-ascii?q?QEOgmCCFngBiyqBGQEBAQ?= X-IronPort-AV: E=Sophos;i="5.47,377,1515456000"; d="scan'208";a="73813741" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Feb 2018 13:52:49 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id w1MDqnlr029684 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Feb 2018 13:52:49 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 22 Feb 2018 08:52:48 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Thu, 22 Feb 2018 08:52:48 -0500 From: "Eric Vyncke (evyncke)" To: Alexandre Petrescu , "int-area@ietf.org" Thread-Topic: [Int-area] Hackathon about PvD at IETF-101 Thread-Index: AQHTqjJIq38Nt96gc0GaA40LrVIjBKOwsgKAgAAnBwA= Date: Thu, 22 Feb 2018 13:52:48 +0000 Message-ID: <382A8CDC-1CEB-43C3-A4AE-388D3F6B45BD@cisco.com> References: <8B2B1A59-7DDC-42D2-A660-A954BEB0368A@cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.56.12] Content-Type: text/plain; charset="utf-8" Content-ID: <8353CDAC96616B4BA41E4393451182E1@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Int-area] Hackathon about PvD at IETF-101 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 13:52:52 -0000 SW5kZWVkLCB0aGFuayB5b3UhDQoNCk9uIDIyLzAyLzE4IDEzOjMzLCAiSW50LWFyZWEgb24gYmVo YWxmIG9mIEFsZXhhbmRyZSBQZXRyZXNjdSIgPGludC1hcmVhLWJvdW5jZXNAaWV0Zi5vcmcgb24g YmVoYWxmIG9mIGFsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb20+IHdyb3RlOg0KDQogICAgUmF0 aGVyIC5vcmcgcmlnaHQ/ICBodHRwczovL3d3dy5uZWF0LXByb2plY3Qub3JnLw0KICAgIA0KICAg IExlIDIwLzAyLzIwMTggw6AgMTE6MDUsIEVyaWMgVnluY2tlIChldnluY2tlKSBhIMOpY3JpdCA6 DQogICAgPiBJZiB5b3Ugd2FudCB0byB0ZXN0IHlvdXIgUHZEIChkcmFmdC1pZXRmLWludGFyZWEt cHJvdmlzaW9uaW5nLWRvbWFpbnMpIA0KICAgID4gaW1wbGVtZW50YXRpb24sIG9yIGhlbHAgd2l0 aCB0aGUgaW50ZWdyYXRpb24gb2YgUHZEIGludG8gTkVBVCBwcm9qZWN0IA0KICAgID4gKEVVLWZ1 bmRlZCBIMjAyMCApIHRoZW4geW91IGFyZSB3ZWxjb21lIHRvIA0KICAgID4gcGFydGljaXBhdGUg dG8gdGhlIGZyZWUgaGFja2F0aG9uIG9uIHRoZSBXRSBiZWZvcmUgdGhlIElFVEYtMTAxLg0KICAg ID4gDQogICAgPiBPcGVuIHNvdXJjZSBjb2RlOiBodHRwczovL2dpdGh1Yi5jb20vSVB2Ni1tUHZE ICgyIGRhZW1vbnMgc2VuZGluZyBSQSArIA0KICAgID4gTGludXggS2VybmVsIHRvIGhhbmRsZSBQ dkQpDQogICAgPiANCiAgICA+IE1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGhhY2thdGhvbjoN CiAgICA+IA0KICAgID4gICAgICAgICAgICAgIA0KICAgID4gU2lnbnVwOiBodHRwczovL3d3dy5p ZXRmLm9yZy9yZWdpc3RyYXRpb24vaWV0ZjEwMS9oYWNrYXRob25yZWdpc3RyYXRpb24ucHkNCiAg ICA+IA0KICAgID4gICAgICAgICAgICAgIE1vcmUgDQogICAgPiBpbmZvcm1hdGlvbjogaHR0cHM6 Ly9pZXRmLm9yZy9ob3cvcnVubmluZ2NvZGUvaGFja2F0aG9ucy8xMDEtaGFja2F0aG9uLw0KICAg ID4gDQogICAgPiAgICAgICAgICAgICAgS2VlcCB1cCB0byBkYXRlIGJ5IHN1YnNjcmliaW5nIHRv Og0KICAgID4gDQogICAgPiAgICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9oYWNrYXRob24NCiAgICA+IA0KICAgID4gLcOpcmljLCAtcGllcnJlIGFuZCAt dG9tDQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAgPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gSW50LWFyZWEgbWFpbGluZyBsaXN0DQog ICAgPiBJbnQtYXJlYUBpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pbnQtYXJlYQ0KICAgID4gDQogICAgDQogICAgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBJbnQtYXJlYSBtYWlsaW5nIGxpc3QN CiAgICBJbnQtYXJlYUBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaW50LWFyZWENCiAgICANCg0K From nobody Thu Feb 22 07:10:35 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A457F12741D; Thu, 22 Feb 2018 07:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.229 X-Spam-Level: X-Spam-Status: No, score=-4.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 9EJ6Py06JG9l; Thu, 22 Feb 2018 07:10:24 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94096127136; Thu, 22 Feb 2018 07:10:24 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id ABFC974646E5E; Thu, 22 Feb 2018 15:10:20 +0000 (GMT) Received: from YYZEML703-CHM.china.huawei.com (10.218.33.73) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 22 Feb 2018 15:10:22 +0000 Received: from YYZEML701-CHM.china.huawei.com ([169.254.4.55]) by YYZEML703-CHM.china.huawei.com ([169.254.5.26]) with mapi id 14.03.0382.000; Thu, 22 Feb 2018 10:10:19 -0500 From: AshwoodsmithPeter To: Lorenzo Colitti , Tom Herbert CC: "int-area@ietf.org" , "ila@ietf.org" , 5GANGIP <5gangip@ietf.org>, Mikael Abrahamsson Thread-Topic: [5gangip] Fwd: New Version Notification for draft-herbert-ipv6-prefix-address-privacy-00.txt Thread-Index: AQHTqyQF3ya/8VzIb0ucLIqjsI2plaOvVBsAgAAEewCAAKRkgIAAHbOAgABrfvA= Date: Thu, 22 Feb 2018 15:10:18 +0000 Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E239AC19AE@YYZEML701-CHM.china.huawei.com> References: <151906718318.18731.8986618406430268357.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: [10.193.60.241] Content-Type: multipart/alternative; boundary="_000_7AE6A4247B044C4ABE0A5B6BF427F8E239AC19AEYYZEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Int-area] [5gangip] Fwd: New Version Notification for draft-herbert-ipv6-prefix-address-privacy-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 15:10:28 -0000 --_000_7AE6A4247B044C4ABE0A5B6BF427F8E239AC19AEYYZEML701CHMchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RWRnZSBkZXZpY2VzIG9ubHkgc3RvcmUgRklCL01hcHBpbmcgZW50cmllcyBvZiB0aGluZ3MgdGhl eSBhcmUgdGFsa2luZyB0bywgdGhhdOKAmXMgYSB2ZXJ5IHRpbnkgZnJhY3Rpb24gb2YgdGhlIDFC IGVudHJpZXMuLg0KDQpQZXRlcg0KDQoNCkZyb206IDVnYW5naXAgW21haWx0bzo1Z2FuZ2lwLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMb3JlbnpvIENvbGl0dGkNClNlbnQ6IFdlZG5l c2RheSwgRmVicnVhcnkgMjEsIDIwMTggMTA6MzggUE0NClRvOiBUb20gSGVyYmVydCA8dG9tQHF1 YW50b25pdW0ubmV0Pg0KQ2M6IGludC1hcmVhQGlldGYub3JnOyBpbGFAaWV0Zi5vcmc7IDVHQU5H SVAgPDVnYW5naXBAaWV0Zi5vcmc+OyBNaWthZWwgQWJyYWhhbXNzb24gPHN3bWlrZUBzd20ucHAu c2U+DQpTdWJqZWN0OiBSZTogWzVnYW5naXBdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1oZXJiZXJ0LWlwdjYtcHJlZml4LWFkZHJlc3MtcHJpdmFjeS0wMC50eHQNCg0K T24gVGh1LCBGZWIgMjIsIDIwMTggYXQgMTA6NTEgQU0sIFRvbSBIZXJiZXJ0IDx0b21AcXVhbnRv bml1bS5uZXQ8bWFpbHRvOnRvbUBxdWFudG9uaXVtLm5ldD4+IHdyb3RlOg0KVGhlIGhpZGRlbiBh Z2dyZWdhdGlvbiBtZXRob2QgaXMgaW50ZW5kZWQgdG8gbWFrZSBzY2FsaW5nIHBvc3NpYmxlLg0K RWFjaCBhc3NpZ25lZCBibG9jayByZXN1bHRzIGluIG9uIGVudHJ5IGluIG1hcHBpbmcgc3lzdGVt IHNvIHRvdGFsDQphbW91bnQgb2Ygc3RhdGUgaXMgbnVtX2hvc3RzKm51bV9ibG9ja3MgcGVyIGhv c3QuIGUuZy4gaW4gYSBuZXR3b3JrIG9mDQoxME0gbm9kZXMgd2l0aCAxMDAgYmxvY2tzIHBlciBo b3N0IHRoYXQncyAxQiBlbnRyaWVzIGluIHRoZSBtYXBwaW5nDQpzeXN0ZW0tLSBzaG91bGQgYmUg YWJsZSB0byBzY2FsZSB0aGF0Lg0KDQpJIGhhdmUgYSBmdW5kYW1lbnRhbCBwcm9ibGVtIHdpdGgg dGhlIGFzc2VydGlvbiAic2hvdWxkIGJlIGFibGUgdG8gc2NhbGUgdG8gMUIgbWFwcGluZyBlbnRy aWVzIiBnaXZlbiB0aGF0IGEpIGN1cnJlbnQgcm91dGluZyBoYXJkd2FyZSBjYXBhYmlsaXRpZXMg YXJlIHRocmVlIG9yZGVycyBvZiBtYWduaXR1ZGUgYXdheSBmcm9tIHRoYXQsIGFuZCBiKSBhbnlv bmUgb24gdGhlIEludGVybmV0IGNhbiBtb3VudCBhIHN0YXRlIGV4aGF1c3Rpb24gYXR0YWNrIG9u IHRoZSBtYXBwaW5nIHN5c3RlbSBzaW1wbHkgYnkgb3JpZ2luYXRpbmcgYSBwYWNrZXQgdG8gYW55 IElQdjYgYWRkcmVzcyBpbiB0aGUgZG9tYWluLg0KDQpQZXJzb25hbGx5IEkgZG9uJ3QgdGhpbmsg dGhpcyB3b3JrIHNob3VsZCBwcm9ncmVzcyB1bnRpbCB3ZSBoYXZlIGxpbmUgb2Ygc2lnaHQgdG8g YSBzeXN0ZW0gdGhhdCBjYW4gYWN0dWFsbHkgZG8gdGhhdC4NCg== --_000_7AE6A4247B044C4ABE0A5B6BF427F8E239AC19AEYYZEML701CHMchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+RWRnZSBkZXZpY2VzIG9ubHkgc3RvcmUgRklCL01hcHBpbmcgZW50cmllcyBv ZiB0aGluZ3MgdGhleSBhcmUgdGFsa2luZyB0bywgdGhhdOKAmXMgYSB2ZXJ5IHRpbnkgZnJhY3Rp b24gb2YgdGhlIDFCIGVudHJpZXMuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+UGV0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IDVnYW5naXAg W21haWx0bzo1Z2FuZ2lwLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkxv cmVuem8gQ29saXR0aTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDIxLCAy MDE4IDEwOjM4IFBNPGJyPg0KPGI+VG86PC9iPiBUb20gSGVyYmVydCAmbHQ7dG9tQHF1YW50b25p dW0ubmV0Jmd0Ozxicj4NCjxiPkNjOjwvYj4gaW50LWFyZWFAaWV0Zi5vcmc7IGlsYUBpZXRmLm9y ZzsgNUdBTkdJUCAmbHQ7NWdhbmdpcEBpZXRmLm9yZyZndDs7IE1pa2FlbCBBYnJhaGFtc3NvbiAm bHQ7c3dtaWtlQHN3bS5wcC5zZSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFs1Z2FuZ2lw XSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaGVyYmVydC1pcHY2LXBy ZWZpeC1hZGRyZXNzLXByaXZhY3ktMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEZlYiAyMiwgMjAxOCBhdCAxMDo1MSBBTSwg VG9tIEhlcmJlcnQgJmx0OzxhIGhyZWY9Im1haWx0bzp0b21AcXVhbnRvbml1bS5uZXQiIHRhcmdl dD0iX2JsYW5rIj50b21AcXVhbnRvbml1bS5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaGlkZGVuIGFnZ3JlZ2F0 aW9uIG1ldGhvZCBpcyBpbnRlbmRlZCB0byBtYWtlIHNjYWxpbmcgcG9zc2libGUuPGJyPg0KRWFj aCBhc3NpZ25lZCBibG9jayByZXN1bHRzIGluIG9uIGVudHJ5IGluIG1hcHBpbmcgc3lzdGVtIHNv IHRvdGFsPGJyPg0KYW1vdW50IG9mIHN0YXRlIGlzIG51bV9ob3N0cypudW1fYmxvY2tzIHBlciBo b3N0LiBlLmcuIGluIGEgbmV0d29yayBvZjxicj4NCjEwTSBub2RlcyB3aXRoIDEwMCBibG9ja3Mg cGVyIGhvc3QgdGhhdCdzIDFCIGVudHJpZXMgaW4gdGhlIG1hcHBpbmc8YnI+DQpzeXN0ZW0tLSBz aG91bGQgYmUgYWJsZSB0byBzY2FsZSB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIGEgZnVuZGFtZW50YWwgcHJv YmxlbSB3aXRoIHRoZSBhc3NlcnRpb24gJnF1b3Q7c2hvdWxkIGJlIGFibGUgdG8gc2NhbGUgdG8g MUIgbWFwcGluZyBlbnRyaWVzJnF1b3Q7IGdpdmVuIHRoYXQgYSkgY3VycmVudCByb3V0aW5nIGhh cmR3YXJlIGNhcGFiaWxpdGllcyBhcmUgdGhyZWUgb3JkZXJzIG9mIG1hZ25pdHVkZSBhd2F5IGZy b20gdGhhdCwgYW5kIGIpIGFueW9uZSBvbiB0aGUgSW50ZXJuZXQgY2FuIG1vdW50IGENCiBzdGF0 ZSBleGhhdXN0aW9uIGF0dGFjayBvbiB0aGUgbWFwcGluZyBzeXN0ZW0gc2ltcGx5IGJ5IG9yaWdp bmF0aW5nIGEgcGFja2V0IHRvIGFueSBJUHY2IGFkZHJlc3MgaW4gdGhlIGRvbWFpbi48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGVyc29uYWxs eSBJIGRvbid0IHRoaW5rIHRoaXMgd29yayBzaG91bGQgcHJvZ3Jlc3MgdW50aWwgd2UgaGF2ZSBs aW5lIG9mIHNpZ2h0IHRvIGEgc3lzdGVtIHRoYXQgY2FuIGFjdHVhbGx5IGRvIHRoYXQuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_7AE6A4247B044C4ABE0A5B6BF427F8E239AC19AEYYZEML701CHMchi_-- From nobody Thu Feb 22 11:53:43 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5751A12DA03 for ; Thu, 22 Feb 2018 11:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uf8DXsUgKRaR for ; Thu, 22 Feb 2018 11:53:28 -0800 (PST) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2467512DA24 for ; Thu, 22 Feb 2018 11:53:15 -0800 (PST) Received: by mail-wr0-x22c.google.com with SMTP id l43so11814543wrc.2 for ; Thu, 22 Feb 2018 11:53:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jsXw7SGi0TD7hB01UNn7+C7G+TtDRPFo12OCwDYhYdY=; b=1RwwvY57QpuZoB/VhTgx/BVjwjlk4bOhaZXFBQI8o5lct3FRpiicQnkY70HnLJ7TvK y1qWQgx9c/pqiHVjLlm9tqjNuZabilcJUBxvK1snTzzaURA6ZXhFHXaywpoLaL8xcMSg Z8wXvo4W26K4DMfvDnj9Mssq2O5+JoWXWiEVTiuo5V8s2uMRBhVVsPFTdyrs/Y7xSxV7 hhY5m8HU8huO/ry+fUwJ62J1XJe6FbNBD1V/xVkIIPYhWiNFQyFntqCuVu7vYQgdvNFk sRrJ69b/IzQBVtrSzLoaBIz3laUqEtFX0dROrxHTyZ0APgPUSIDgGblKwXR/3NeDt+Rj 6Kuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jsXw7SGi0TD7hB01UNn7+C7G+TtDRPFo12OCwDYhYdY=; b=Q8pjnUMIDF6jq8AjVi3VZUCzZo8cvusM999onu0vZ+D2IFrzfGwERKWq87ArYxvTaY 5ByaP8j3wULAf+k5+Y3LssoBsMVUVFiqPMHpLLdrooO7ahTSSk1Vp1mjXGO/hpp69MZT XVy4A/LqWsqaCXjk1icUBtpw2A45zJNqEfRZCCsBXZC9eiT1vbMfiSbU5VAXCyTbWdwH 63x8wYtoWMv7GOIdehUFOWkBj33yPcL60mwiWw5KgTTfIc5FlM+JHO2/YAI/ORMJSeC1 z28Cw64kK0Yonf+rVSkojQZzL/dJXGdjk0Y5fWCtYmM0m7nrrbIXnRqLqCs+Z9oYbKnC j01Q== X-Gm-Message-State: APf1xPCP3qY5VeP0oiZmBEz7ZffnRT6OCxYnlkz9WtS1mAY2Xu5u/zcz /VCOfvLAhN0iJdPcXSQuplZBXPlguUhM1zarxVKPFg== X-Google-Smtp-Source: AH8x225mADQyFdoSrk0wPz47Ls7lslp2u0nkwzm10opcx65u+x5IcX2HmJ13CzVZJaKZ9Miulew4vtkQ/0HRaw0UMsM= X-Received: by 10.223.131.133 with SMTP id 5mr6773261wre.153.1519329193559; Thu, 22 Feb 2018 11:53:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.135.74 with HTTP; Thu, 22 Feb 2018 11:53:13 -0800 (PST) Received: by 10.223.135.74 with HTTP; Thu, 22 Feb 2018 11:53:13 -0800 (PST) In-Reply-To: References: <151906718318.18731.8986618406430268357.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Thu, 22 Feb 2018 11:53:13 -0800 Message-ID: To: Lorenzo Colitti Cc: Mikael Abrahamsson , ila@ietf.org, int-area@ietf.org, 5GANGIP <5gangip@ietf.org> Content-Type: multipart/alternative; boundary="94eb2c0d2940e120030565d26441" Archived-At: Subject: Re: [Int-area] [5gangip] Fwd: New Version Notification for draft-herbert-ipv6-prefix-address-privacy-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 19:53:29 -0000 --94eb2c0d2940e120030565d26441 Content-Type: text/plain; charset="UTF-8" On Feb 21, 2018 10:38 PM, "Lorenzo Colitti" wrote: On Thu, Feb 22, 2018 at 10:51 AM, Tom Herbert wrote: > The hidden aggregation method is intended to make scaling possible. > Each assigned block results in on entry in mapping system so total > amount of state is num_hosts*num_blocks per host. e.g. in a network of > 10M nodes with 100 blocks per host that's 1B entries in the mapping > system-- should be able to scale that. I have a fundamental problem with the assertion "should be able to scale to 1B mapping entries" given that a) current routing hardware capabilities are three orders of magnitude away from that, and b) anyone on the Internet can mount a state exhaustion attack on the mapping system simply by originating a packet to any IPv6 address in the domain. Personally I don't think this work should progress until we have line of sight to a system that can actually do that. Lorenzo, The intent of this draft is to articulate a problem that may be worth working on. It's not to specify the solution, although I think it makes sense to at least suggest some possible paths for a solution to establish that the problem is solvable. Also, there is not necessarily just one possible solution. The draft mentions possibly of hybrid assignment of addresses for different privacy requirements, and how NAT is an existing technique that can provide strong privacy in addressing (I hope there is a better solution that does not rely on NAT). Tom --94eb2c0d2940e120030565d26441 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Feb 21, 2018 10:38 PM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
On Thu, Feb 2= 2, 2018 at 10:51 AM, Tom Herbert <tom@quantonium.net> wrote= :
The hidden aggregation method is intend= ed to make scaling possible.
Each assigned block results in on entry in mapping system so total
amount of state is num_hosts*num_blocks per host. e.g. in a network of
10M nodes with 100 blocks per host that's 1B entries in the mapping
system-- should be able to scale that.

I have a fundamental problem with the assertion "should be able to s= cale to 1B mapping entries" given that a) current routing hardware cap= abilities are three orders of magnitude away from that, and b) anyone on th= e Internet can mount a state exhaustion attack on the mapping system simply= by originating a packet to any IPv6 address in the domain.

<= /div>
Personally I don't think this work should progress until we h= ave line of sight to a system that can actually do that.
<= /div>

Lorenzo,

The inte= nt of this draft is to articulate a problem that may be worth working on. I= t's not to specify the solution, although I think it makes sense to at = least suggest some possible paths for a solution to establish that the prob= lem is solvable. Also, there is not necessarily just one possible solution.= The draft mentions possibly of hybrid assignment of addresses for differen= t privacy requirements, and how NAT is an existing technique that=C2=A0 can= provide strong privacy in addressing (I hope there is a better solution th= at does not rely on NAT).

Tom


--94eb2c0d2940e120030565d26441-- From nobody Thu Feb 22 17:35:17 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1567F126BF6; Thu, 22 Feb 2018 17:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 cMJgs2L2-Jkf; Thu, 22 Feb 2018 17:34:59 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C804812E8B0; Thu, 22 Feb 2018 17:34:28 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 5630FB80C92; Thu, 22 Feb 2018 17:34:23 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, int-area@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20180223013423.5630FB80C92@rfc-editor.org> Date: Thu, 22 Feb 2018 17:34:23 -0800 (PST) Archived-At: Subject: [Int-area] =?utf-8?q?RFC_8335_on_PROBE=3A_A_Utility_for_Probing_I?= =?utf-8?q?nterfaces?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 01:35:03 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8335 Title: PROBE: A Utility for Probing Interfaces Author: R. Bonica, R. Thomas, J. Linkova, C. Lenart, M. Boucadair Status: Standards Track Stream: IETF Date: February 2018 Mailbox: rbonica@juniper.net, rejithomas@juniper.net, furry@google.com, chris.lenart@verizon.com, mohamed.boucadair@orange.com Pages: 19 Characters: 35084 Updates: RFC 4884 I-D Tag: draft-ietf-intarea-probe-10.txt URL: https://www.rfc-editor.org/info/rfc8335 DOI: 10.17487/RFC8335 This document describes a network diagnostic tool called PROBE. PROBE is similar to PING in that it can be used to query the status of a probed interface, but it differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Instead, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface, or it can reside on a node to which the probed interface is directly connected. This document updates RFC 4884. This document is a product of the Internet Area Working Group 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 Official Internet Protocol Standards (https://www.rfc-editor.org/standards) 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 https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk 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 nobody Mon Feb 26 12:01:35 2018 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5600812D80F for ; Mon, 26 Feb 2018 12:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=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 FVQGgY1osv9P for ; Mon, 26 Feb 2018 12:01:27 -0800 (PST) Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA2A312D88C for ; Mon, 26 Feb 2018 12:00:57 -0800 (PST) Received: by mail-wm0-f46.google.com with SMTP id t6so11256927wmt.5 for ; Mon, 26 Feb 2018 12:00:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=yHGR1Pb0b5go91eMARQoUq3Z1lVoY4gkJI0/dLOpWgM=; b=cNo+h6vdLNGZysmplJBv+utnlyYDm4gB5nri7U+Rn7PL01wuM1sXMlDfAqOuAIQZpc PqMySEuxo0AHXL3Vrsp0xvsvp0+dhGQ6PIofi3ZDCBC458gzNYnf6ZKb4oPGZb4X1sFJ gzJrzpn3pfrvJ1vZta1eGwnoCLlx50vS4hHr/yiTEaC8Z1FuzitvWNpgSXdF0FPt7yve hxvytXM3BsyQMzV5KeVvo8F7lsHcC/jmEsqmxmVackVV4dRf0I8x0z/9BWbHgzDwGbDW 5Fs0/Yf2fgOMaxWaBdHGYjvKX6WBc2IiAG5a8vQ1Sa+1aj7X8nzH4ZEJ5l9DXvbwVxN+ k+5w== X-Gm-Message-State: APf1xPDV5HfbA0lWnTuf1sFOLtkg7VGp78WfOfGx4/EfE7UBaM3Co4oP fItoi6UWX1ZlnJFtYIRwYswcnsACtgE= X-Google-Smtp-Source: AH8x227Xy1j0QOm0yLYsinu8XAlvbb6ez9Rr8BmkFec80tdRjWg9rKGmSnoBuwvrJDBUnnWaByiqZg== X-Received: by 10.80.137.135 with SMTP id g7mr16081471edg.100.1519675255743; Mon, 26 Feb 2018 12:00:55 -0800 (PST) Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id 8sm7190276edw.72.2018.02.26.12.00.54 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 26 Feb 2018 12:00:54 -0800 (PST) Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 7c13eb94; Mon, 26 Feb 2018 20:00:53 +0000 (UTC) Date: Mon, 26 Feb 2018 20:00:53 +0000 From: Job Snijders To: ietf@ietf.org Cc: int-area@ietf.org Message-ID: <20180226200053.GE7536@vurt.meerval.net> References: <20180223013423.5630FB80C92@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180223013423.5630FB80C92@rfc-editor.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.3 (2018-01-21) Archived-At: Subject: Re: [Int-area] RFC 8335 on PROBE: A Utility for Probing Interfaces X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 20:01:29 -0000 Dear all, Are there any open source reference implementations available for this utility? Kind regards, Job On Thu, Feb 22, 2018 at 05:34:23PM -0800, rfc-editor@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. > > > RFC 8335 > > Title: PROBE: A Utility for Probing > Interfaces > Author: R. Bonica, > R. Thomas, > J. Linkova, > C. Lenart, > M. Boucadair > Status: Standards Track > Stream: IETF > Date: February 2018 > Mailbox: rbonica@juniper.net, > rejithomas@juniper.net, > furry@google.com, > chris.lenart@verizon.com, > mohamed.boucadair@orange.com > Pages: 19 > Characters: 35084 > Updates: RFC 4884 > > I-D Tag: draft-ietf-intarea-probe-10.txt > > URL: https://www.rfc-editor.org/info/rfc8335 > > DOI: 10.17487/RFC8335 > > This document describes a network diagnostic tool called PROBE. > PROBE is similar to PING in that it can be used to query the status > of a probed interface, but it differs from PING in that it does not > require bidirectional connectivity between the probing and probed > interfaces. Instead, PROBE requires bidirectional connectivity > between the probing interface and a proxy interface. The proxy > interface can reside on the same node as the probed interface, or it > can reside on a node to which the probed interface is directly > connected. This document updates RFC 4884. > > This document is a product of the Internet Area Working Group 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 Official > Internet Protocol Standards (https://www.rfc-editor.org/standards) 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 > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk > > 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 nobody Tue Feb 27 15:14:01 2018 Return-Path: X-Original-To: int-area@ietf.org Delivered-To: int-area@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D518112E8EE; Tue, 27 Feb 2018 15:11:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: int-area@ietf.org, suresh@kaloom.com X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151977307186.5200.16317801980204093899.idtracker@ietfa.amsl.com> Date: Tue, 27 Feb 2018 15:11:11 -0800 Archived-At: Subject: [Int-area] intarea - Requested session has been scheduled for IETF 101 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 23:11:12 -0000 Dear Wassim Haddad, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. intarea Session 1 (1:30:00) Monday, Afternoon Session II 1550-1720 Room Name: Sandringham size: 300 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Internet Area Working Group Area Name: Internet Area Session Requester: Wassim Haddad Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: t2trg lisp saag dhc 6lo v6ops 6man 6tisch lpwan Second Priority: softwire sunset4 tsvwg dnsop netconf nfvrg People who must be present: Wassim Haddad Suresh Krishnan Juan Carlos Zuniga Resources Requested: Special Requests: ---------------------------------------------------------