Re: I-D Action: draft-linkova-6man-default-addr-selection-update-00.txt

Jen Linkova <furry13@gmail.com> Fri, 07 April 2017 13:04 UTC

Return-Path: <furry13@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 7F7CE12946C for <ipv6@ietfa.amsl.com>; Fri, 7 Apr 2017 06:04:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 ACc4nLoCZOC1 for <ipv6@ietfa.amsl.com>; Fri, 7 Apr 2017 06:04:32 -0700 (PDT)
Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 6A50A1200F1 for <ipv6@ietf.org>; Fri, 7 Apr 2017 06:04:32 -0700 (PDT)
Received: by mail-io0-x22e.google.com with SMTP id l7so48689836ioe.3 for <ipv6@ietf.org>; Fri, 07 Apr 2017 06:04:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n0mfrL+zu57pqyo+p0RkeK71qpBIkK2Fjb0xX/ixQOw=; b=rdgFmuCf8DjRQxL3DFqz76E9sVi4DprD0XroV1fnElTLGsSjkb2FMw6dG8VSOL/4s3 Xo47EOjzqogcMAtZtZig88YBBiYJiRhlKxtyJFgYsFP6yl9cwGRTGknTfwTP9Qmp2h03 VcLbMDOkWX0W1lCQnZSqBiWO9STX2sRmmO9OnzpudfIPdRozYQU2M5aCenyJvobV9V1m znPRLisZTKegqp4jqg8lUU/1esR85j1pZf44o2wb2iUo1ElD7ZdOZVayE9NFLUT8dBDR cETWKrYZzQfwo3FaEzUu2u5m3OxQTzO3f/XHuQlKxVvtIo/zRp5F0j8FXjUPIYHk6429 +PNQ==
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=n0mfrL+zu57pqyo+p0RkeK71qpBIkK2Fjb0xX/ixQOw=; b=g8v1isXLbscAeq8YpRsJfDpbLJCZmweZxhGXsD2c4LXaEHj8vCyp9pWAWL0/KQAe4I Ubdhekh+z3WYsixc7Z49aZhLWZQdG8AOVu4jOkmhumXtRvg0RXyeehcEMDTVjnlI5THy mRaYkBb1Mmf1nm2CiePE1kbUi9COJ7XzhHSE5E4nfLb2ONAOwNPpitjZmtAVvlKEJrZh NvWwZ3WvYN/eXu4AXgwqbtjyrK2nYmyVZ9E1Kz3mr7KC+YOPHkF0T3wy2BYNr4r9yiQz ZqFbLWpRwhqXwQ6Q0BZeUoyQCZ0VSWfcnCssSaq5uH/OdqoKPn0L4gfxkT8nSIdB3+sq E5UQ==
X-Gm-Message-State: AFeK/H0XUG2J7Rs+lLQyzgLMHd0MDc51LY9RDpvMXI2qEncDELLTP7lJveQINmM+Ve5G7tgqpflZQ2wHPyBKGQ==
X-Received: by 10.107.136.96 with SMTP id k93mr37654793iod.20.1491570271744; Fri, 07 Apr 2017 06:04:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.184.197 with HTTP; Fri, 7 Apr 2017 06:04:11 -0700 (PDT)
In-Reply-To: <CAO42Z2wREkid1tCNCQz9HriFC_xD9K=WB=vS4UO3oEHMSfsN7g@mail.gmail.com>
References: <149093611351.8864.5121956820429281359@ietfa.amsl.com> <1f8d497b-3286-2074-7c2e-f224ceda55a8@gmail.com> <CAO42Z2wREkid1tCNCQz9HriFC_xD9K=WB=vS4UO3oEHMSfsN7g@mail.gmail.com>
From: Jen Linkova <furry13@gmail.com>
Date: Fri, 07 Apr 2017 15:04:11 +0200
Message-ID: <CAFU7BAR1ZJBnu=+pjNGYD37YghXhYRTJAUpcSd=XvtJY=4k4UA@mail.gmail.com>
Subject: Re: I-D Action: draft-linkova-6man-default-addr-selection-update-00.txt
To: Mark Smith <markzzzsmith@gmail.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, 6man <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ZSsfkrNav_Jh4mxHF9uYyHw4Mmg>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 07 Apr 2017 13:04:34 -0000

On Wed, Apr 5, 2017 at 4:35 AM, Mark Smith <markzzzsmith@gmail.com> wrote:
> On 5 April 2017 at 08:18, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>> As far as I can see this proposal makes sense and should work. But:
>>
>>>    1.  The link-local address of the router in the new layer 2 domain
>>>        might be the same as the link-local address of the "old" router
>>>        (it's quite common to have link-local address on routers to be
>>>        explicitly configured, especially in VRRP-enabled environments)
>>
>> Wow. Shouldn't there also be an operational recommendation to configure
>> non-clashing or at least highly-unlikely-to-clash addresses for
>> such routers?
>>
>
> I think RFC8064, "Recommendation on Stable IPv6 Interface Identifiers"
> is indirectly making that recommendation.
>
> One of the use cases of RFC7217 is for router interface's Link-Local
> addresses, and to not use use the interface's MAC address as the
> Net_Iface value (e.g., module/slot number, ifindex instead), so that
> the router's Link-Local IID is both unique and doesn't change if the
> physical interface module is replaced, which usually means an
> interface MAC address change too.

I probably need to make the text a bit more clear but the use case
I've observed has nothing to do with SLAAC, so neither
RFC 7217 nor RFC8064 are applicable here. People do configure VRRP LLAs manually
(see http://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/virtual-link-local-address-edit-interfaces.html
and http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-2/addr_serv/configuration/guide/b_ipaddr_cg42crs/b_ipaddr_cg42crs_chapter_01010.html#task_96270599CAEE43DDB370F262D8C0722A
for two random examples)

and it's understandable that they do not want to generate an unique
LLA for each interface (LLAs are supposed to be unique within a link,
right? so it's perfectly fine to have fe80::1 configured on each
interface).
It's operational reality, it does make sense (or we shall stop
pretending that  LLAs have link scope...;( ) so I believe it would be
nice to tweak the source address selection a bit to deal better with
the real life..;)


-- 
SY, Jen Linkova aka Furry