Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06

Andrew McGregor <andrewmcgr@gmail.com> Fri, 26 April 2013 03:43 UTC

Return-Path: <andrewmcgr@gmail.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 78B2A21F8E5D for <ietf@ietfa.amsl.com>; Thu, 25 Apr 2013 20:43:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7J+qnA8QsxOm for <ietf@ietfa.amsl.com>; Thu, 25 Apr 2013 20:43:18 -0700 (PDT)
Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id 2696021E803D for <ietf@ietf.org>; Thu, 25 Apr 2013 20:43:17 -0700 (PDT)
Received: by mail-lb0-f179.google.com with SMTP id t1so3406610lbd.10 for <ietf@ietf.org>; Thu, 25 Apr 2013 20:43:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=I3WpHb1dzwmD/1iPQzv0UHJpT0Q+qHh8c5oqqt6TvXE=; b=TvCr8z6Gqf7OJUJmW1ev57hCzgqjLTOWwpHfIoaAerinX+cAe8KlOT+9Why5pNhM+L QRk0hpdxTnEgE5O9GHgp3PgTRRYBGwX4W86c0hS2W32iPgc7/yhYsXHvcWjkwUmJ1dUc diCYSpSB3xcUkKF2RqfMM35NccbcMzIWfYsxghSYC+Yo5xTf6D3y2D7xLW8RdB2SkOB8 +kzvBhZ1wLfNDynxw5zDZ94LKA1eBA1Edrb6XJtnF3wgi58OluslgHrRysbK00of1qAm wney0w+6iUfUIbrjQUm8espoLsOBnI/dnQlviOCrNnMY4Hcd4dfu0lys4uIde7qmjeMs /XHg==
MIME-Version: 1.0
X-Received: by 10.112.159.1 with SMTP id wy1mr20838931lbb.80.1366947797118; Thu, 25 Apr 2013 20:43:17 -0700 (PDT)
Received: by 10.112.131.71 with HTTP; Thu, 25 Apr 2013 20:43:17 -0700 (PDT)
In-Reply-To: <023601ce4193$81d5e640$4001a8c0@gateway.2wire.net>
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> <C91E67751B1EFF41B857DE2FE1F68ABA0C050FCB@TK5EX14MBXC273.redmond.corp.microsoft.com> <023601ce4193$81d5e640$4001a8c0@gateway.2wire.net>
Date: Fri, 26 Apr 2013 13:43:17 +1000
Message-ID: <CAA_e5Z7siAGELG+J9H7t-_ggj6wXFY2M4fK=-n=OwPE08Hx-tQ@mail.gmail.com>
Subject: Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06
From: Andrew McGregor <andrewmcgr@gmail.com>
To: "t.p." <daedulus@btconnect.com>
Content-Type: multipart/alternative; boundary="001a11c33e64dfb69d04db3b5515"
Cc: Christian Huitema <huitema@microsoft.com>, ietf <ietf@ietf.org>, SM <sm@resistor.net>
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: Fri, 26 Apr 2013 03:43:19 -0000

Further to that, ifindexes of tunnels and PPP sessions can change
dynamically as the bearer connection goes up and down, even if the
interface has the same name and authenticated identity.  That raises the
interesting question of whether even the interface name is stable, as on
many systems it is pure chance if the same name-identity mapping repeats
itself.

If you want a stable address, you want to use something that actually has
the exact stability properties you require, and interface indexes and names
are seldom what you actually need.

Andrew


On Thu, Apr 25, 2013 at 7:00 PM, t.p. <daedulus@btconnect.com> wrote:

> ----- Original Message -----
> From: "Christian Huitema" <huitema@microsoft.com>
> To: "Fernando Gont" <fgont@si6networks.com>; "SM" <sm@resistor.net>
> Cc: "RJ Atkinson" <rja.lists@gmail.com>; <ietf@ietf.org>
> Sent: Tuesday, April 23, 2013 6:02 PM
>
> <snip>
>
> 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.
>
> <tp>
>
> The ifIndex, as it appears in the IF-MIB is not stable; it can change
> on each and every re-boot of a system, depending on the order in which
> modules are loaded.  It remains the same only until the next re-boot. I
> do not know what impact this has on the ipi6_ifindex as used in the
> IPv6 API, whether that in turn is unstable.
>
> (This is a property of the IF-MIB and is a reason why the YANG
> equivalent
> has used a name to index the interface table and not the index value,
> which may give the users of the YANG module, also currently in Last
> Call, an interesting migration problem).
>
> So if you want a stable address, perhaps you should not use the
> interface index.
>
> Tom Petch
>
> </tp>
> 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
>
>
>
>
>