RE: last call comments for draft-ietf-6man-stable-privacy-addresses-06
Christian Huitema <huitema@microsoft.com> Tue, 23 April 2013 17:02 UTC
Return-Path: <huitema@microsoft.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C5E21F9709 for <ietf@ietfa.amsl.com>; Tue, 23 Apr 2013 10:02:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bciTyxlX9mZr for <ietf@ietfa.amsl.com>; Tue, 23 Apr 2013 10:02:55 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id 5874121F9703 for <ietf@ietf.org>; Tue, 23 Apr 2013 10:02:55 -0700 (PDT)
Received: from BL2FFO11FD007.protection.gbl (10.173.161.203) by BL2FFO11HUB019.protection.gbl (10.173.160.111) with Microsoft SMTP Server (TLS) id 15.0.675.0; Tue, 23 Apr 2013 17:02:51 +0000
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD007.mail.protection.outlook.com (10.173.161.3) with Microsoft SMTP Server (TLS) id 15.0.675.0 via Frontend Transport; Tue, 23 Apr 2013 17:02:50 +0000
Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.175]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Tue, 23 Apr 2013 17:02:14 +0000
From: Christian Huitema <huitema@microsoft.com>
To: Fernando Gont <fgont@si6networks.com>, SM <sm@resistor.net>
Subject: RE: last call comments for draft-ietf-6man-stable-privacy-addresses-06
Thread-Topic: last call comments for draft-ietf-6man-stable-privacy-addresses-06
Thread-Index: AQHOP15AmJeRabuWb0mZCsaFLdinaJjihbgAgAAeFQCAABByAIABToYAgAACAJA=
Date: Tue, 23 Apr 2013 17:02:13 +0000
Message-ID: <C91E67751B1EFF41B857DE2FE1F68ABA0C050FCB@TK5EX14MBXC273.redmond.corp.microsoft.com>
References: <C5E21A29-4336-469A-B799-3E9BCDFBF3B5@gmail.com> <6.2.5.6.2.20130422081720.0db4ca38@resistor.net> <51759238.8000306@si6networks.com> <6.2.5.6.2.20130422125704.0d551178@resistor.net> <5176B8A2.40809@si6networks.com>
In-Reply-To: <5176B8A2.40809@si6networks.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.74]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(44976003)(63696002)(69226001)(76482001)(49866001)(50466001)(47736001)(51856001)(50986001)(56816002)(33656001)(55846006)(56776001)(47446002)(81542001)(77982001)(54356001)(31966008)(74662001)(79102001)(54316002)(46406003)(20776003)(59766001)(6806003)(53806001)(47776003)(81342001)(74502001)(47976001)(4396001)(65816001)(23726002)(66066001)(16406001)(46102001)(80022001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB019; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 08252193F3
Cc: RJ Atkinson <rja.lists@gmail.com>, "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Apr 2013 17:02:56 -0000
After reading the document again, the main issue is that the document specifies a solution to a problem by detailing a specific implementation, but does not explain the design choices behind that solution. As such, we end up with an over constrained specification, which at the same time fails to explain the problems at hand. The specification aims at providing addresses that are "stable and different," so that the same host connecting will have different and uncorrelated addresses when connecting to different networks, but will keep the same address when connecting repeatedly to the same network. As Mike St-Johns pointed out, the solution is trivial: create a different random number each time the host connect to a new network; make sure that the same random number is reused if the host reconnect to the same network. The latter property can be achieved either by keeping of log of previously visited networks and the corresponding address, or by using a "master random number" and combining it with the identification of the visited network. In theory, that's about all what the IETF ought to specify. Instead, the draft goes into great details on how to actually implement the random number generator. Apart from not being necessary, some of these details are wrong. For example, the suggested algorithm includes an "interface index," but different operating systems have different ways of enumerating interfaces, and the variations in enumeration could end up violating the "stable address" property. I would suggest reworking the draft to separate a normative section, effectively a variation of the 3 lines paragraph above, and an informational section, the current specification of the algorithm as "an example of a way to achieve this result if the operating system meets certain condition, like stable interface identifiers." I would also explain the inherent issues that have to be solved, e.g., swapping interfaces, or enabling multi-homed hosts. And I would observe that the DAD problem cannot be solved ina reliable way. -- Christian Huitema
- last call comments for draft-ietf-6man-stable-pri… Eliot Lear
- last call comments for draft-ietf-6man-stable-pri… RJ Atkinson
- Re: last call comments for draft-ietf-6man-stable… Sam Hartman
- Re: last call comments for draft-ietf-6man-stable… Martin Rex
- Re: last call comments for draft-ietf-6man-stable… Michael StJohns
- Re: last call comments for draft-ietf-6man-stable… Fernando Gont
- Re: last call comments for draft-ietf-6man-stable… Eliot Lear
- Re: last call comments for draft-ietf-6man-stable… SM
- Re: last call comments for draft-ietf-6man-stable… Fernando Gont
- Re: last call comments for draft-ietf-6man-stable… Fernando Gont
- Re: last call comments for draft-ietf-6man-stable… Philipp Kern
- Re: last call comments for draft-ietf-6man-stable… Eliot Lear
- Re: last call comments for draft-ietf-6man-stable… SM
- Re: last call comments for draft-ietf-6man-stable… Mark Smith
- Re: last call comments for draft-ietf-6man-stable… Fernando Gont
- RE: last call comments for draft-ietf-6man-stable… Christian Huitema
- RE: last call comments for draft-ietf-6man-stable… Christian Huitema
- Re: last call comments for draft-ietf-6man-stable… Fernando Gont
- Re: last call comments for draft-ietf-6man-stable… Fernando Gont
- RE: last call comments for draft-ietf-6man-stable… Christian Huitema
- Re: last call comments for draft-ietf-6man-stable… Fernando Gont
- Re: last call comments for draft-ietf-6man-stable… SM
- Re: last call comments for draft-ietf-6man-stable… t.p.
- Re: last call comments for draft-ietf-6man-stable… Andrew McGregor
- Re: last call comments for draft-ietf-6man-stable… Ole Troan
- Re: last call comments for draft-ietf-6man-stable… Michael Richardson
- Re: last call comments for draft-ietf-6man-stable… Fernando Gont
- Re: last call comments for draft-ietf-6man-stable… Fernando Gont
- Re: last call comments for draft-ietf-6man-stable… Randy Presuhn