Re: IPv6 Formal Anycast Addresses and Functional Anycast Addresses (Fwd: New Version Notification for draft-smith-6man-form-func-anycast-addresses-01.txt)

Mark Smith <markzzzsmith@gmail.com> Sun, 03 November 2019 23:36 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 54C7C12003E for <ipv6@ietfa.amsl.com>; Sun, 3 Nov 2019 15:36:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.497
X-Spam-Level:
X-Spam-Status: No, score=-0.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, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, 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 Oz8QJApUq8Hb for <ipv6@ietfa.amsl.com>; Sun, 3 Nov 2019 15:36:15 -0800 (PST)
Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (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 4123A120026 for <6man@ietf.org>; Sun, 3 Nov 2019 15:36:15 -0800 (PST)
Received: by mail-oi1-x230.google.com with SMTP id y194so12619090oie.4 for <6man@ietf.org>; Sun, 03 Nov 2019 15:36:15 -0800 (PST)
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=1Dp+hgohZCZgCxKlDCutEHCbn3AbjiMnPKBINAF0gms=; b=TRkJtpFpPeb5iNjc+aG5B1NXu/Qj6KMInEnlZALF6i+1PwkfYrnv8PtuKn6SY3rAO/ zzxy5QGcrkz0Arb/Ri8jUSBdmMqXNlcfTccHXN2rHzgyQQdesddb5tQhWRMoog0WJaAn IRpGzy23EoqF8N0PqO2C/WjE5wUK5mXxlwQcQL7eqdDR0OJSjlaz6QHoM/8+JdjtpX/Y sDo99d0/kKecDAPZJHoLd06R+CJI4v6ltfRYFmbvgGBIxK78YDDA/YOiJiXtFucBrarn 9gZknZudhITMg4ZdXBk63fy2prahNDtlbnt8w5iSEV2rdWOOb3bDz6wq1GSF3PgvMk/2 nC5g==
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=1Dp+hgohZCZgCxKlDCutEHCbn3AbjiMnPKBINAF0gms=; b=ArqXjbPZuStMKjdOwAGFIdiR+m2f+7XbXfXET5OH/d4073gQEke5R5+2ma2rAkxgiV lo+jjk5eFIedmPRexvWmxaCS47eMyZe2UbiOEuRneOZDkLEsTq4xMB/hAHwn/XRl7W+4 NEwkPOYfqfpQrghzW4T/SCPRF/0XJY7Ksj/9DNCEk1yg1D2vypsyh6vnQfogtIH5CHkW HWPQIXZgU4+abRhG7MlaQEOv6JWbmjuI/s4BUZywVd19LVWTfo+uYYUAt3Cgf5AqfmvE Za1EF91DwsER74JgXr5WBqt/DimW2W8jbOFb0tIDCEa4SmCDiWfU91vQnGCtd0EeNknb K0Wg==
X-Gm-Message-State: APjAAAVShObcGG+KdP4wFteAezura5MgDwE8I+JeSdMICArq+U+hsdMy bzxIGbDnoVpRFhYVK9MpaukAopa3r0Lc7bk75XQ=
X-Google-Smtp-Source: APXvYqxUnvNfgXa7JogHympNGO008zHVNQuoPXev8f0S/Q9ltp3GJut+7NXgm5RhPireP0v8Y88fh8h1bukSQiAOQfA=
X-Received: by 2002:aca:2211:: with SMTP id b17mr11165539oic.38.1572824174373; Sun, 03 Nov 2019 15:36:14 -0800 (PST)
MIME-Version: 1.0
References: <157277906705.13535.345852921709779212.idtracker@ietfa.amsl.com> <CAO42Z2wSU-puDaQq-PzTCTE=S3qyqUNrPhH0pgOEO_d3=StnHA@mail.gmail.com> <b97c15c0-b1fe-0d78-0897-5fc4bb6a9a34@foobar.org> <B42E6EED-5620-49BE-BB3D-B1CF6F04A1CC@gmail.com> <20191103212712.GK2287@faui48f.informatik.uni-erlangen.de> <B2A9EAB8-BF52-4302-BB77-70EE252F45E5@gmail.com> <20191103225223.GL2287@faui48f.informatik.uni-erlangen.de>
In-Reply-To: <20191103225223.GL2287@faui48f.informatik.uni-erlangen.de>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Mon, 4 Nov 2019 10:36:03 +1100
Message-ID: <CAO42Z2y3KOkhWVy4_0UQawmqUZz2ibD5ok=9-YVR12RjguvMmA@mail.gmail.com>
Subject: Re: IPv6 Formal Anycast Addresses and Functional Anycast Addresses (Fwd: New Version Notification for draft-smith-6man-form-func-anycast-addresses-01.txt)
To: Toerless Eckert <tte@cs.fau.de>
Cc: Fred Baker <fredbaker.ietf@gmail.com>, 6MAN <6man@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000352de9059679aae8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/bcSNN21HLNU3ILFu4O28NPzUuj8>
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: Sun, 03 Nov 2019 23:36:17 -0000

On Mon, 4 Nov 2019, 09:52 Toerless Eckert, <tte@cs.fau.de>; wrote:

> On Sun, Nov 03, 2019 at 05:24:36PM -0500, Fred Baker wrote:
> > Funny. It doesn't work that way in DNS. Every root server simply thinks
> that one of its addresses is the anycast address and so accepts the packet
> as "directed to it". It also responds from that address, so that the
> requester recognizes the response.
>
> Sure. responses to a single request packet as in DNS are fine. Just
> a connection of multiple packet exchanges is not architectural
> clean with anycast. Aka: DNS over TCP would likely work
> in most cases, but not if for example there is an ECMP node
> to two root servers along the path.
>

Combine anycast with a multipath transport layer protocol, and you can
establish the initial connection using anycast, and then immediately switch
to unicast.

See:

5.7.7 <https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-01#section-5.7.7>;.
Multipath Transport Layer Protocols

https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-01#section-5.7.7

Of course, if that setup is too costly for your transaction, then you
probably can accept the risk of anycast forwarding inconsistency during the
transaction. It's packet loss to recover from. Redo the small transaction
if it fails.

That being said, the IPv6 flow label is supposed to be used to provide a
consistent ECMP path for a flow.


Using the IPv6 Flow Label for
      Equal Cost Multipath Routing and Link Aggregation in Tunnels


https://tools.ietf.org/html/rfc6438


Regards,
Mark.


> Cheers
>    toerless
>
> > > On Nov 3, 2019, at 4:27 PM, Toerless Eckert <tte@cs.fau.de>; wrote:
> > >
> > > It is somewhat architecturally dissatisfying that (AFAIK) we seem to
> need to
> > > resolve limitations of anycast addresses at the transport layer,
> > > e.g.: redirecting connection requests to an anycast address to a
> > > unicast address of the transport responder. If initiators would know
> an address is
> > > an anycast address, they could use some TBD network layer (ICMP)
> extension
> > > to do that resolution independent of individual transport protocols.
> > >
> > > And the network layer would only know it needed to do this if there was
> > > a way for the initiator to identify an address as an anycast address
> > > AFAIK (can't think of a simpler way).
> > >
> > > Cheers
> > >    toerless
> > >
> > > On Sun, Nov 03, 2019 at 01:59:24PM -0500, Fred Baker wrote:
> > >> On Nov 3, 2019, at 9:23 AM, Nick Hilliard <nick@foobar.org>; wrote:
> > >>> If you create an anycast protocol which has characteristics which
> are sufficiently different to unicast that it requires a separate
> addressing schema, then by all means it would be appropriate to create an
> addressing schema to fit in with this.  The determinant here would be that
> global unicast addresses would not be usable for this protocol. Until then,
> a separate address block is mostly a matter of aesthetics.
> > >>
> > >> I would agree. I did some poking around to identify anycast address
> groups. The IANA has records for three. RFC 4291 has a fourth, which is
> subnet anycast which is supposed to get a packet to a router I'm not sure I
> can say how widely deployed any of those are.
> > >>
> > >>
> https://www.iana.org/assignments/ipv6-anycast-addresses/ipv6-anycast-addresses.xml
> > >> RFC 2526             Mobile IPv6 Home-Agents anycast
> > >> ETSI EN 302 636-6-1  IPv6 over GeoNetworking geographic anycast
> > >> RFC 4291             IPv6 Anycast Subnet-Router Anycast Address
> > >>
> > >> On the other hand, there are a number of unicast addresses in daily
> use worldwide as anycast, which are the addresses one uses to access the
> DNS root. Collected statistics tell us that on the order of 10% of DNS
> requests to the root use IPv6, and the rest are IPv4. So I would say that
> the use of unicast addresses as anycast has a strong supporting case.
> > >>
> > >> https://www.iana.org/domains/root/servers
> > >> https://root-servers.org/
> > >>
> > >> The one use case that your draft mentions that seemed to be new was
> that of a network operator that wanted to deploy an anycast service, but
> only to its customers. It, however, seemed to be hypothetical. Do you know
> of operators or services that have that requirement?
> > >>
> > >> In other words, I'm wondering whether there is a problem being
> solved, or an architectural preference.
> > >> --------------------------------------------------------------------
> > >> IETF IPv6 working group mailing list
> > >> ipv6@ietf.org
> > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > >> --------------------------------------------------------------------
> > >
> > > --
> > > ---
> > > tte@cs.fau.de
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> --
> ---
> tte@cs.fau.de
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>