RE: default-iids: Clarifying the use of stable addresses

Mark Smith <markzzzsmith@gmail.com> Sun, 22 May 2016 22:21 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC1612D16F for <ipv6@ietfa.amsl.com>; Sun, 22 May 2016 15:21:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Level:
X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 J3hUpNCeevjb for <ipv6@ietfa.amsl.com>; Sun, 22 May 2016 15:21:48 -0700 (PDT)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 BDE6512D100 for <ipv6@ietf.org>; Sun, 22 May 2016 15:21:47 -0700 (PDT)
Received: by mail-vk0-x229.google.com with SMTP id f66so202392066vkh.2 for <ipv6@ietf.org>; Sun, 22 May 2016 15:21:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=zKzVqPJ8Zn8plCrFnd+8GZwY1BoIzA4SB5QB4XbXAtk=; b=K3YvbZJkoZBwcF0opWoftWIh4ub6OifXDgz2yPVooWfyWn/QQGNEgBGyTnARbT0DAb rYRl8L5pAz2lk+NHlp5Q206ERIlCNHx2snbzvTAlT4UYM5Zd6JDsIcdg085sbo0VgjhZ JSZMpmSwnT+kjUAFzMJNfuy/UK2h0OvaWNXOxfXh7TA/dlUeaqniOSQOgGK9/VATJ0tf 6LdjNA75mxXZR+l2XXeL5noAtNAfk0925oL68fGi5tECcz7LwIBYk0GJqLaxSjojcKwx gdgp68llbzgtyve068cS0caBjg+kYYYB8ifKbkoLj7kchYLQcvVatKfP8LwDsqKGUhV4 y0DQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=zKzVqPJ8Zn8plCrFnd+8GZwY1BoIzA4SB5QB4XbXAtk=; b=josCGnjP3Rs+ysNweNLBWm9tVCvMCSn8O4Yn6WKNFHmw8/WHoQj4Alnl6MOygnAPre VdsT9Z+rHO9xaRQ8u1GR/TJ+jHncFD7xn6dVmYQtSG/BBBzU0f2oTqYTxIoyD4imXoPX PSIxLEsZwItvF2WuL2TRG2567a18ZrDT3/WtHIgdk0rOGhX4sOI8wnwdiWsGO31YGgMB TyLWHeKk7QonOq7cBiAe41LW+J9h9Mmi3Qg2QtEdWt8ZA88lQKFJiSNSL6oYxeVt3SNR dHNBhLKWEDAbsF1cRqwHXB/bHaCykxjng8gldB2YxlQTfJV3nE2GiWk0MbKbTWZhgegG 1GYA==
X-Gm-Message-State: AOPr4FV+/D2B7ATk9lC8v8cKRVAYSeSQvxhlyz6mHONMDU356AG3q7EGPbWSZvVLQolBAuhoyinTQVClXxfYYQ==
MIME-Version: 1.0
X-Received: by 10.159.37.100 with SMTP id 91mr7041231uaz.67.1463955706653; Sun, 22 May 2016 15:21:46 -0700 (PDT)
Received: by 10.176.3.168 with HTTP; Sun, 22 May 2016 15:21:46 -0700 (PDT)
Received: by 10.176.3.168 with HTTP; Sun, 22 May 2016 15:21:46 -0700 (PDT)
In-Reply-To: <CAO42Z2wtpns24PW2P0-TayEWcB1ar2Ez8a997Sf-vvin8z3fMQ@mail.gmail.com>
References: <573F3F49.9090107@si6networks.com> <ce73a827-a137-eab3-3b1e-9e4895d9b6bd@gmail.com> <CAO42Z2yg9pGFrzf69LHAhKxrZ0dOH3=FUP0k3ZjeGN8dMp3Xww@mail.gmail.com> <3c68ee5b9ff748c8bddcff7ad8ed7a31@XCH15-06-11.nw.nos.boeing.com> <CAO42Z2wtpns24PW2P0-TayEWcB1ar2Ez8a997Sf-vvin8z3fMQ@mail.gmail.com>
Date: Mon, 23 May 2016 08:21:46 +1000
Message-ID: <CAO42Z2wfbRPsZqwRFfkeUw6ZoNqXMoUyr5-4D4GXkkYfgStnWQ@mail.gmail.com>
Subject: RE: default-iids: Clarifying the use of stable addresses
From: Mark Smith <markzzzsmith@gmail.com>
To: Albert E Manfredi <albert.e.manfredi@boeing.com>
Content-Type: multipart/alternative; boundary="94eb2c122da4dcb25f053375bfca"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/9iPGRzuhdeZhqfHtrP2GEV7KQAc>
Cc: 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 22 May 2016 22:21:49 -0000

On 23 May 2016 5:31 AM, "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
wrote:
>
> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Mark Smith
>
> > The roles of 'client' or 'server' are application layer concepts.
> > It is only IPv4 NAT that has created the requirement to consider
> > devices at the network layer to be 'clients' or 'servers'. As we
> > don't need to do NAT in IPv6, we don't need to both classify and
> > constrain ourselves to thinking of devices as exclusively being
> > only one of either a 'client' or a 'server'.
>
> Except that NAT also exists with IPv6,

So it is experimental.

The terms ''client' and 'server' don't exist in RFC2460 nor RFC791, so
there are no such roles in these protocols. Hosts are only packet senders
or receivers to or from their network layer peers.

I'm not arguing against stable addresses. I see use cases relevant to me
for temporary only (my smart phone), temporary + stable (my tower PC at
home that I use as both a client and a server for different apps) and
stable only (routers that I need to login to to administer and whose
interface addresses are used by hosts and other routers).

I think the mistake Lorenzo might be making is confusing stable with
permanent and unchangeable "to the end of time".

RFC7217 addresses are not permanent. An operator can cause one to change at
any time, by reinitialising the algorithm with a different secret key or
other parameters that will cause the IID to change. A fresh OS install will
cause new ones to be generated. The computer itself will be replaced at
some point, and that should cause new RFC7217s to be generated.

A virtual machine will be able to persist in operation much longer than
hardware, however at some point its operating system and software is likely
to become obsolete and replaced. If that possible time span is too long,  a
policy of generating new addresses every 5 years could be put in place.

MAC addresses are permanent, as they're burnt into the card. Yet how many
permanent MAC addresses from the NICs in the 2000s, 1990s or earlier would
be in use today? Permanence in computing isn't very permanent.

I think very few RFC7217 addresses will exist for any longer than 10 years.
The few that do can be easily changed if necessary, for the use cases where
stable addresses are necessary or desirable.

Regards,
Mark.

> Bert
>