Re: Generic anycast addresses...

Mark Smith <markzzzsmith@gmail.com> Fri, 31 May 2019 01:05 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 D15CE120019 for <ipv6@ietfa.amsl.com>; Thu, 30 May 2019 18:05:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
X-Spam-Status: No, score=-0.499 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.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 VWxDOEZeGrP3 for <ipv6@ietfa.amsl.com>; Thu, 30 May 2019 18:05:20 -0700 (PDT)
Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::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 18D41120048 for <6man@ietf.org>; Thu, 30 May 2019 18:05:19 -0700 (PDT)
Received: by mail-oi1-x229.google.com with SMTP id b21so2527949oic.8 for <6man@ietf.org>; Thu, 30 May 2019 18:05:19 -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:content-transfer-encoding; bh=21RU9nCr57O3H6YE+FHm5TNq9GeqmuHUh/HdWrc7prU=; b=OXIfvB4Xy3wLrHaNRAEKoip8Bx+nIonQSHRqLqVplWkEtriixqH76TuYn/rzjfM1rz xwXQ/PDLlaDc6bz1+xNGPreHi9OVKo03cczRWZ1KAEC9jgNSmO6DGCmH1X3IkEPexO94 TX3kVucoqUGMmLLBC3ouZo3j4UUf+igNzoaQ4vsXPzl+OcC5FjFbXxS00YYB06wFzC0O cDq5Yvy6BbWJcZ0nUdqOzFY2ZQkrXmGAQ654nkvUebKa7ehWEwsk5e7dxdqqb4g7t7EN oMNNwacH1VOBBOSiAnPTjOgSN/i7+fL66E4wLIlrMeuxNX4FWoRAi70Uhq4DtpdH8eGP yrZA==
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:content-transfer-encoding; bh=21RU9nCr57O3H6YE+FHm5TNq9GeqmuHUh/HdWrc7prU=; b=euyhkSRVMaHsyj9iog35i1BHUH2aQf6YLNYFo0fSN7lSqP0yb5lxUpY0GrF03sMraP 9yE1+iVNJOvaTLh6bhorIsqikK9EqCCBKRXyCglgTUlukAr6lcx6M6YgxMMP/4Dhh9LZ UdUwepYW7kV7uLB8CoxKs25rQrHCvPkKckNTnzXQuaGBKGuPcHGrCcsl6v5Y6mKw107w VKeNPevoN8BsXVBuejh0BwUY8m4Qz75ww6xxSSiyIVlkDAJbmIgi1ZY2MagGSivHh+2a Ce2HKH5aZ+dBHKAtKwExhFUUj6yGjckrfrNw90r5Iy5O7nrdgK3AhqsjLuWTQcuPvzut Mklg==
X-Gm-Message-State: APjAAAXE+Y8U/W20YG2D83kmbdcHi/M5yjurQfC1HHbb6P1O6+E8Hw7b 9Ji7y/3+9WcWAsMjzSiC1KghfEhivTDEQEknCks=
X-Google-Smtp-Source: APXvYqwFlkRj4/eUmJE/R8NkOUvLXFUdCWNsDbg3h50CPWvl7IMtW6OxBCpxzQE6yI+LAl9+4m6PCipVvGldV4aVHfo=
X-Received: by 2002:aca:5591:: with SMTP id j139mr4598704oib.38.1559264719275; Thu, 30 May 2019 18:05:19 -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> <D6E27B45-437F-45BE-A305-47DD460BCE02@fugue.com> <26144.1559226966@localhost> <1DD451A7-D898-4105-974C-53776A3DA9F2@fugue.com> <20190530152902.l2nmyhadr4e4kt7x@faui48f.informatik.uni-erlangen.de> <0FF19D6D-1A45-41EF-BE34-CC35B5E51E1E@steffann.nl> <D91629F6-73AC-4A80-80EF-16644F73DA36@fugue.com> <701687d4-842c-6a16-3c97-349125324e3f@gmail.com> <D648647D-60E1-4DCE-B0BE-11002E0AE5A4@fugue.com> <1F907710-D143-4BB5-9660-0A2E0C85BD2D@gmail.com>
In-Reply-To: <1F907710-D143-4BB5-9660-0A2E0C85BD2D@gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Fri, 31 May 2019 11:04:52 +1000
Message-ID: <CAO42Z2xCBQMFQi0HOUQE7S7GY8APMvsJN8jeJXWz2ZHceQCfGg@mail.gmail.com>
Subject: Re: Generic anycast addresses...
To: Fred Baker <fredbaker.ietf@gmail.com>
Cc: Ted Lemon <mellon@fugue.com>, Michael Richardson <mcr+ietf@sandelman.ca>, "6man@ietf.org" <6man@ietf.org>, Dave Thaler <dthaler@microsoft.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Kszm6DIOp3E3NLkpiK9hxHmz7kE>
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: Fri, 31 May 2019 01:05:22 -0000

On Fri, 31 May 2019 at 10:15, Fred Baker <fredbaker.ietf@gmail.com> wrote:
>
>
>
> > On May 30, 2019, at 2:59 PM, Ted Lemon <mellon@fugue.com> wrote:
> >
> > Do ULAs have a non-fuzzy scope boundary?
>
> The recommendation of RFC 4193, if I understand it, is that advertisements of ULA prefixes in EBGP are "not announced", and if they happen to be announced by accident, are refused. https://tools.ietf.org/html/rfc4193#section-4.1.
>

>From memory, I suggested that at the time, and the motivation was to
try to avoid by default ULA private address space route leaks we've
seen with the RFC 1918 address space, more recently with 100.64/10,
and other non-global address spaces.

The idea was to facilitate trading ULA routes through more specifics
if e.g. two ULA domains were to be joined together after a company
merger, but to not have it occur automatically upon bringing up eBGP.

BCP38 would also be another cause of ULA packet drops at customer/ISP
network boundaries.

Regards,
Mark.


> That is in no sense a default. My primary expertise is with my former employer's equipment, but I believe this to be generally true: EBGP only advertises what it is told to, and refuses only what it is told to. Hence, I would guess that the typical configuration will not advertise a ULA in anything resembling a normal case, but will not refuse one that is advertised to it.
>
> But the intended scope-boundary is "EBGP".
> --------------------------------------------------------------------------------
> Victorious warriors win first and then go to war,
> Defeated warriors go to war first and then seek to win.
>      Sun Tzu
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------