Globally Unique Link Local Addresses (Re: about violation of standards)

Mark Smith <markzzzsmith@gmail.com> Tue, 23 April 2019 09:58 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 5A13F1203D8 for <ipv6@ietfa.amsl.com>; Tue, 23 Apr 2019 02:58:15 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 CoCcUqD6hwQe for <ipv6@ietfa.amsl.com>; Tue, 23 Apr 2019 02:58:13 -0700 (PDT)
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 616B21203C8 for <ipv6@ietf.org>; Tue, 23 Apr 2019 02:58:13 -0700 (PDT)
Received: by mail-ot1-x330.google.com with SMTP id f10so12244596otb.6 for <ipv6@ietf.org>; Tue, 23 Apr 2019 02:58:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1jHw/40sdeEqibKzJdfL8WWuudmZHEYCM1iZe9XdHdg=; b=WrZrE3zPmTGHGKPjeDfoA0HOv5DYT7vqNJi6CPDFAMZoJbwIp2TAxRrGb02Qrs1ftp aZ1yArtJidkhAOoesrSHzlQ9QJy8GUaEYGBgY4N2eDAqpVwGvXNKUp8OYepp2vCVkaim l2icF3t90/Lmy+EmfqgdfAEfzM8BSGSshYJz1UxvAU2N7VpYUH1NFzwMhxqSKMkFnEfJ 0mgJtgizi2k+t03XCqubIvtJMDnhTKVMcCNGsACbqrQsFxM8dqf1QJ5XBDOuni6jyDq1 LdIvg5b84HkfAcMIKel8ZtQm7d7StLh8K+oMGUMzSEu0nJkitql65vqfck9CgwYlCTM1 8PpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1jHw/40sdeEqibKzJdfL8WWuudmZHEYCM1iZe9XdHdg=; b=Dm0JmqsM45HSuLf5J/wnlk2+BHHotxEleUyVXMYnAhPlKCC1fXWUh242nt9fcw0jW5 gaCJNdAgf9ZKbmxiJdS1OhCpcNC89pr9JDRcGQ6pfVw/xF2pLlBnaGkrQgA6vNJjcNtl yy9xlEPg0izbdvV1YoyKvzHy0QMUF99WgQ3Ka7wv0FJuUYyZEcLx0FWwbehf5T0jfOXj BXQ3E4QJc/pY5d7Piybe2W8s39tWzLceFfmnzciVh3B74b9DO76ZAYguDyMszBeurEva OXpRUdcGdVvihvk0NpCBfUbNkGsOWlUg4PefNBcdGlao+8nDQNz1pZodj8pBWiCFr1ad AP/A==
X-Gm-Message-State: APjAAAU8LUMJQLt/EIsNCi6F221fp+XBlVRodVGIiNsMOL4unmJER4Vg BDU4L22JQTArDl7qSw9B1CqEfGALNIYrbdPcDwk=
X-Google-Smtp-Source: APXvYqyoBb/DVxWCymgGwL1naiGktmk0G9XAIbgE7YSbK0A7iFwTmX+2NqjPsfroj4DmrvRrSd/cw4djQc6syqhYBQU=
X-Received: by 2002:a9d:1c3:: with SMTP id e61mr1736037ote.285.1556013492527; Tue, 23 Apr 2019 02:58:12 -0700 (PDT)
MIME-Version: 1.0
References: <bb7f7606-2adf-e669-8bcd-e41f17800782@gmail.com> <CAJE_bqd9frqX5-yeVPj8MYXpZ4737HqK1gmfD9cQV3A-Ea5HrQ@mail.gmail.com> <6bd5db47-408a-727e-5c13-f34a3465f986@si6networks.com> <CAJE_bqfTLqRbLp4fLu2ASZuZ+4G5c2G+RXkO92kXfLgPTqBnng@mail.gmail.com> <EEF00EA7-2AAF-403F-99AD-1D53ED18E8B3@cisco.com> <47631828-121F-402D-8165-969684C1101B@employees.org>
In-Reply-To: <47631828-121F-402D-8165-969684C1101B@employees.org>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Tue, 23 Apr 2019 19:57:46 +1000
Message-ID: <CAO42Z2wbq=8f6FfR7DoOOFrY7B5puxS26Dk+SsM71Pk7y03ipQ@mail.gmail.com>
Subject: Globally Unique Link Local Addresses (Re: about violation of standards)
To: Ole Troan <otroan@employees.org>
Cc: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Fernando Gont <fgont@si6networks.com>, Alexandre Petrescu <alexandre.petrescu@gmail.com>, 6man WG <ipv6@ietf.org>, 神明達哉 <jinmei@wide.ad.jp>
Content-Type: multipart/alternative; boundary="0000000000007ce3e705872f9f11"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/saEfsFBHNWQMWpQCbsKK55q-Rfk>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 23 Apr 2019 09:58:15 -0000

On Tue., 23 Apr. 2019, 17:33 Ole Troan, <otroan@employees.org> wrote:

> > Some functions in the router are complex to implement because same value
> for a link local address appears on multiple interfaces.
>
> Like what?
>


I don't specifically know about complex to implement router functions,
however it would be simpler for applications to not have to special case
Link-Local addresses and use sin6_scope_id.


> > It would be useful to be able to encode an abstract interface ID
> somewhere in the /64. Legacy 00 would mean unspecified...
>
> Sounds like you need subnet-id election?
>

Here's how I've thought you could do it for quite a while.

I've thought the best idea would be to have a subnet ID that is generated
using the same/similar algorithm ULAs are generated with, to try to avoid
subnet ID collision across links attached to interfaces on the same
multihomed host or router.

A name could be Globally Unique Link Local Addresses (GULLAs) or Unique
Link Local Addresses (ULLAs). (I'd think the first, just because its a more
easily pronounceable word.)

1. First node on the link looks at the RAs that it receives due to its RSes.

2. If none of them have a PIO for a subnet within the GULLA aggregate
prefix (which may be fe80::/10), it generates a subnet ID per the ULA
algorithm, resulting in the link's GULLA Subnet Prefix.

3. The node starts advertising RAs containing the GULLA Subnet PIO. If the
node is a host, the Router Lifetime is 0. The GULLA Subnet PIO lifetimes
are not Infinite, unlike the lifetimes for the traditional LL prefix and
addresses. Lifetimes in this PIO probably should be the RFC 4861 defaults.
(If the node is also a router, it would advertise any other PIOs in the
same RA, with a non-zero router life time if it is a default router.)

4. Second node on the link, due to its RSes, would see that another node is
already announcing a GULLA Subnet PIO in one of the received RAs.

5. Second node starts also issuing RAs also containing the GULLA Subnet
PIO. Again, if the node is a host, RA router lifetime of zero.

6. 3rd and subsequent nodes attached to the link have some sort of election
or selection algorithm to determine which one or ones take over if the
first or both nodes stop issuing periodic RAs containing the GULLA Subnet
PIO.

Ideally it would be good to have non-GULLA nodes also learn and use this
new GULLA Subnet, learning it from the GULLA RA announcing nodes. However,
that would mean that the fe80::/10 prefix couldn't be used, because
per-RFC4861, nodes are to ignore RA PIOs for the Link-Local prefix. So the
GULLA aggregate prefix would have to be outside of fe80::/10.

The above is mostly inspired by very distant memories of how Appletalk seed
routers work to convey cable range (network prefix) information to other
Appletalk routers on the link.

Regards,
Mark.




>
> Ole
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>