Re: Generic anycast addresses...

George Michaelson <ggm@algebras.org> Thu, 30 May 2019 01:12 UTC

Return-Path: <ggm@algebras.org>
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 D00D912004C for <ipv6@ietfa.amsl.com>; Wed, 29 May 2019 18:12:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=algebras-org.20150623.gappssmtp.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 pbJcLVZ8Dh7c for <ipv6@ietfa.amsl.com>; Wed, 29 May 2019 18:12:50 -0700 (PDT)
Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 62ECD12003F for <6man@ietf.org>; Wed, 29 May 2019 18:12:50 -0700 (PDT)
Received: by mail-it1-x12f.google.com with SMTP id m141so7276420ita.3 for <6man@ietf.org>; Wed, 29 May 2019 18:12:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a+ufJhiN+ARto4prpU1GakTE+Q2PL8Xnq+6X8dpK3vw=; b=UFS52ZYQUQxf0rxE4RNlHgAFo60n9rb008oz9pnFA3zXbOc+a9Hh0e6J2A0Hk1thws OXQJQtBOpQp/HgBC6agywJJ6ugBsHbUD1NUWvlOL592AOIGzsE+Nnt2S+4TOJCWD6ELs UbgseTOyN7gL111gFQJu+CnDHoB1ZigX10QsoiyAoSpgJvYxJsBFP1oHL8tgWMr8LrxC 3PAiO/y6fYl2WpYvvnGM88DWrVDmMa+15hVIp/OYEBILXUw/SsdKMYyw3coVszc1mLd7 qGysqZ8v4c6Mxcp9kkhhCicpBrtlwOLURqfdtv3naR8RZBBCu9RiO8dvir5bteqQX36V /UeQ==
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=a+ufJhiN+ARto4prpU1GakTE+Q2PL8Xnq+6X8dpK3vw=; b=o1efAS4OJ0zP7lAelfIXjv5oZT5nwrDG6Ak/yUBCJBnPqV+hQwaKWUIZttsZSjpdh/ s/luHHzHLaaGYrgx4P006DVVvtETRtA7xWMBPZyLm/sqVshOTbxrsI3sSJ+vsPgHWFF+ VeHgxznsrZquplwXAvLWdWzg8qUvosRtuWfWJ6YtDnmDJLcjooqWcI2WfDr6x9Z8z5GC PwrO0aNYfioeaYx/w4KRfkmuoX01r7872PVttkLnOIYccAzZRmqHbd86+/FkypZxiF8I A35q9/GUGR/uiu60afQjMpG5r78PUcV4DfTmIlkBHq6l49V/2oGwUg4hvqaLZkj/I9JW BG+A==
X-Gm-Message-State: APjAAAWM55fuvm+dAlAAZv589o9h9921G96FzEKLpOWsj6qxpn/EgJJL punAKyUj/JyKOjIjyTctr5xP6u5yzd9RQrBsjtKyNQ==
X-Google-Smtp-Source: APXvYqybcA1ZtEnXAWktZ+h3SaTMBb5odvqoermQD6qTMCy45ti494w6r+vMIMDd7tvmTw9Uv33CCfHnHqiR0Yysq80=
X-Received: by 2002:a24:910b:: with SMTP id i11mr1092273ite.76.1559178769648; Wed, 29 May 2019 18:12:49 -0700 (PDT)
MIME-Version: 1.0
References: <D22E680C-3EE3-4AD7-90C0-9339DA2E5A29@fugue.com> <BN6PR21MB04978DB375C05CB3CE4C914EA31F0@BN6PR21MB0497.namprd21.prod.outlook.com> <4EF97F31-1F39-4150-B044-955C46E96FB4@fugue.com> <20190530002833.wfvjfbj2lv2ig664@faui48f.informatik.uni-erlangen.de> <7A9560FC-0393-45DF-8389-B868455AC6DD@fugue.com> <20190530005734.7d2alod2zoaemmhc@faui48f.informatik.uni-erlangen.de> <CAO42Z2xkM=jBhseNOCc+Kjg__YfSk2v_mTs9OwQQp+04u2zc4Q@mail.gmail.com>
In-Reply-To: <CAO42Z2xkM=jBhseNOCc+Kjg__YfSk2v_mTs9OwQQp+04u2zc4Q@mail.gmail.com>
From: George Michaelson <ggm@algebras.org>
Date: Thu, 30 May 2019 11:12:38 +1000
Message-ID: <CAKr6gn0NZ6DfP4Ws4UZc-7s_X=NQb=HECzsOJV8GuK_uGiiu2Q@mail.gmail.com>
Subject: Re: Generic anycast addresses...
To: Mark Smith <markzzzsmith@gmail.com>
Cc: Toerless Eckert <tte@cs.fau.de>, "6man@ietf.org" <6man@ietf.org>, Dave Thaler <dthaler@microsoft.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/RnGa999ettktgVjcS22EBKMrmd8>
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: Thu, 30 May 2019 01:12:53 -0000

point of information. the RIR system exists, and in the ULA
discussions it was understood that globally unique assigned address
processes were RFC bound in RFC2050 and subsequently RFC7020.

If it becomes necessary to implement the service, the RIRs already
indicated they understood how to manage ULA distribution with
uniqueness, and mechanisms to apply normal address services like
WHOIS.

I guess I'm saying "just because we don't, doesn't mean we can't"

-G

On Thu, May 30, 2019 at 11:08 AM Mark Smith <markzzzsmith@gmail.com> wrote:
>
> On Thu, 30 May 2019 at 10:58, Toerless Eckert <tte@cs.fau.de> wrote:
> >
> > I cant brainstorm a lot more without more details of what you're
> > trying to achieve, and  therefore what the constraints are.
> >
> > Worst case, you float the idea to a single ULA prefix defined
> > by your RFCs mecanism and see how reviewers like this. At least its
> > a lot better than trying to define a "well known" rfc1918
> > anycast address - because your application defined ULA
> > prefix has a very low probability of colliding with somebodies
> > actually used ULA prefix.
>
> Per RFC4193 4.1 and the route propagation constraint, ULAs effectively
> have an organisation scope by default. That may be too small or too
> large for other anycast use cases.
>
> If there is a reserved well-known ULA prefix, then RFC 4193 would have
> to be updated to exclude that value from the algorithm. We also don't
> know if the chosen well-known ULA prefix is already in use somewhere.
>
> I think a better idea is a formal class of anycast addresses with fine
> grained scopes that match (or are) the multicast address scopes.
>
> "IPv6 Formal Anycast Addresses and Functional Anycast Addresses"
> https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-00
>
>
> > On Wed, May 29, 2019 at 05:41:04PM -0700, Ted Lemon wrote:
> > > Indeed, the propagation pattern of a ULA would work nicely for this, but there???s no way to do this automatically.   I might have (and indeed unfortunately it???s common to have) more than one ULA on a constrained network.   How do I pick?   :)
> > >
> > > So what I really want is indeed something that is treated like a ULA, but that can be a constant, and not something that has to be derived.
> >
> > --
> > ---
> > tte@cs.fau.de
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------