IETF Logo Mail Archive

Re: Generic anycast addresses...

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 30 May 2019 23:46 UTC

Return-Path: <brian.e.carpenter@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 522F4120113 for <ipv6@ietfa.amsl.com>; Thu, 30 May 2019 16:46:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, 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=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 ue50wpp29aSg for <ipv6@ietfa.amsl.com>; Thu, 30 May 2019 16:46:52 -0700 (PDT)
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 E6AED120048 for <6man@ietf.org>; Thu, 30 May 2019 16:46:51 -0700 (PDT)
Received: by mail-pl1-x62b.google.com with SMTP id d21so3206462plr.3 for <6man@ietf.org>; Thu, 30 May 2019 16:46:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Q/eOQND9PwCIFLcoP3ujHi70KdpwFCZpodrgB2Q1X0s=; b=F1TNS93QyMXXr4Vpkgi+pdfrPKo+BbeAJPRszXHuq4+va2Bs5E5uL5uQ15ZhUXCDl+ 7ZFB8YsU36sn7/3qwcf8i3OfNTEgR0lz5fzGswrB2hKDhSRVl7OY/MKgoBkGbe/Ylv2n LymJ9d0Craxw0qjKqo4U+51wiVkGOx6Meo8f4WEu552FkO2tCIGxSghBLJzQnR9oCIbx ndyGcAqmwuDoEau1YJvH1MrrAVIeIedRM0WObWnkti9sC6m9Rt+qsDOfTPqCEAJoZOs3 u6+n3FJ4eb9mZWNINk5AflxRSeDWDUFwEEiaZPTlNJdH6BNyDAQnpThIN5wpmfIH8H2b 9Z+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Q/eOQND9PwCIFLcoP3ujHi70KdpwFCZpodrgB2Q1X0s=; b=c6DCNmnzfUq4PNjRsnsjgWl4xoIlHqoSpVJ2WrYZ655ayTC3ufFbi+EQf6WPLTJ5qm CWWm7W77SH1g3NY7YsrO5yT9PAk14DXWLmJT61VYFfbnExVGDv+F/z6ESyyYGX6+h6OA nVhe3uf/dnOZtz9IOsF0+acHn2MYFIGQ7DSTxgXAFbY8k+u9sQvObJIIZw9GcfMxiZCY V3VYFbS7ArSnrzQ6SylS2SVGVYzGWCeZqQzZqqrnlnUdN9WG//3QJ0JydAzLWAFhvDCp DDzlM9Ci/ySVR5u3AwVOFe1g01ScAavOSdzLcJHC7SjNQ01eh8eeCmmwILsRJIeByO1v yjLg==
X-Gm-Message-State: APjAAAVPkg7Ufzhc7rvgbfpBYKrfq/JNirU8YQHXvmxw2HjFsDuZUb0T tagfcJkYPvfz7WkmlbitXmY=
X-Google-Smtp-Source: APXvYqxD7Zjkrfrbha5dvX/dzFdJNTrv/zSKB+6CuMhBDvPZJ2ZiSHgQJAkS4w1AhWviz96XZETdzQ==
X-Received: by 2002:a17:902:9343:: with SMTP id g3mr6088247plp.260.1559260011432; Thu, 30 May 2019 16:46:51 -0700 (PDT)
Received: from [192.168.178.30] (229.129.69.111.dynamic.snap.net.nz. [111.69.129.229]) by smtp.gmail.com with ESMTPSA id m101sm9350938pjb.2.2019.05.30.16.46.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 May 2019 16:46:50 -0700 (PDT)
Subject: Re: Generic anycast addresses...
To: Ted Lemon <mellon@fugue.com>, Sander Steffann <sander@steffann.nl>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "6man@ietf.org" <6man@ietf.org>, Dave Thaler <dthaler@microsoft.com>
References: <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> <20190530220838.g2hshonsjxmfnd55@faui48f.informatik.uni-erlangen.de> <632BE7EC-26A6-44E9-9CCD-F0AE143D4256@fugue.com> <AF1967FC-526D-47FB-98BE-F9B949F26796@steffann.nl> <ED6DA426-630A-4056-83F5-DE61FDA21EF5@fugue.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <c091024d-18f2-5564-e87d-0a80b945b606@gmail.com>
Date: Fri, 31 May 2019 11:46:47 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <ED6DA426-630A-4056-83F5-DE61FDA21EF5@fugue.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/XXCELGdLhnx2IqiIMoTmxO6vGdU>
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 23:46:53 -0000

On 31-May-19 11:04, Ted Lemon wrote:
> On May 30, 2019, at 3:53 PM, Sander Steffann <sander@steffann.nl <mailto:sander@steffann.nl>> wrote:
>> I like the scope aspect of Mark's draft. ULA is always organisation or site scoped, and should be filtered as such. Anycast that have a different scope should have different boundaries. Anycast addresses that have ISP scope can cross from the customer's network to the ISP's network, while there should be a boundary between that customer's ULA addresses and that ISP's ULA addresses (let's assume they both use ULA for this example).
> 
> I agree that this makes sense in principle.   But I think it’s a lot fuzzier than you’re at least allowing for.   As I pointed out previously, what “ISP scope means” when you are at a site that’s multi-homed is impossible to specify, because there is more than one scope that could be called “ISP scope,” and the scopes are disjoint.
> 
> Therefore I would prefer not to wait for this seemingly intractable problem to be solved before solving the problem that I’m actually trying to solve.

That is probably wise. But anyway, if the desired scope of your anycast
address is set by routing policy, it surely doesn't matter what the prefix
is? If you support 2001:0db8:f000:baaa:f000:baaa:f000:baaa as an anycast
address, it's up to you to determine exactly how far out from the user
that address is filtered (site boundary, ISP boundary, or further).
Even for multihomed sites, that remains true.

Either that or specify a maximum allowed hop limit.

BTW we did perform a long term experiment with the anycast prefix
2002::/16, and some would say that it showed the risk of such things.

    Brian

v2.23.0 | Report a Bug | By Email