IETF Logo Mail Archive

Re: Generic anycast addresses...

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 04 June 2019 03:06 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 D66D71200F4 for <ipv6@ietfa.amsl.com>; Mon, 3 Jun 2019 20:06:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] 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 HWvosbGz_HeK for <ipv6@ietfa.amsl.com>; Mon, 3 Jun 2019 20:06:30 -0700 (PDT)
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 B9F5F12004B for <6man@ietf.org>; Mon, 3 Jun 2019 20:06:30 -0700 (PDT)
Received: by mail-pf1-x436.google.com with SMTP id d126so11780927pfd.2 for <6man@ietf.org>; Mon, 03 Jun 2019 20:06:30 -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=XtUGv8WRdJd/wE4F1biaG2+L5kVXMn8W/XnLjTQm7oE=; b=ZVV3SvpO5z8rdbJVZnkb78YBOBUkx+Nfxb8XyS6f1lHONLp5mZUMto+lBIzgmDdSbj NL7Nmw3LXUJpuBr5rYghF7Q5BP+w86ozUSsw2+tPhE1PwuvuWPoIrxULk/Yu3D/TMDnS BDdnWA8Rovtldgb2MHKEmfZLQuyuyarE2eoe+oT7StW1iX+b1qP5yr+VugVi/wRJvSrs uTpKasOKQZMyE+LTGL687yGStjWtjhiciLhS5n94gVqHOX0RFm2BdefyeX81VhtuNjuG yiJrXw5Nom78pIRJSUWp4Qv2szd7V+dQDiYuMDfRPMmEuVIPplPKw6a3BVUtmJ/k+FHd r2pA==
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=XtUGv8WRdJd/wE4F1biaG2+L5kVXMn8W/XnLjTQm7oE=; b=KAVnBnSzG3mzAJWUZwb8m3HxDFe7dB+ihD/KmIUfVl+kHb2NYsCBfKI30x8dHdAx7z Whw2C96JddcDY9kiF/8fNrjcfL8V+yhWQVBZ0we35by2R/wetMjAKKk0QoZYjzhaYlIP vdkyAwa3yS1YXG6Gt5xf93Lb6iXzEgnGg57uOEYpkJSpPdMi7NznbzSA6vXvFVhIRWob H8zXyDETTOfxE04UOoVmrbWA2TsR+Wtau6SxoNYjs8iyk61W6wdLIutU4idkKflBsggF MH9Q1JQHSEEHXOelgcljMfm9CdATsd5w8rIrOWb+2xzjmuwu9gS34Dgxs8+SJaZosWr5 SerQ==
X-Gm-Message-State: APjAAAUwNu01elwpaOlCcAlDrB5BcJ9NZ6JvS9V1jhWnyof2LwhIEzkR 055FpFMtwvdLutB91Ar5IRoqeSPq
X-Google-Smtp-Source: APXvYqwqizQNmTn1PiICE1iJhU80hTe838x2RBh3tuZLoq0hMLmUgtNslZ0Yzp33WKVVZvOdtinFRw==
X-Received: by 2002:a65:6559:: with SMTP id a25mr32697171pgw.33.1559617589925; Mon, 03 Jun 2019 20:06:29 -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 p20sm27607451pgk.7.2019.06.03.20.06.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jun 2019 20:06:28 -0700 (PDT)
Subject: Re: Generic anycast addresses...
To: Michael Richardson <mcr+ietf@sandelman.ca>, Christian Huitema <huitema@huitema.net>
Cc: 6MAN <6man@ietf.org>
References: <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> <25631.1559317738@localhost> <CAO42Z2x9iTrbvZuCxqSpDX-CQ9MtY8V1yyb-hg+XYtXXYn7LKg@mail.gmail.com> <9021.1559397908@localhost> <CAO42Z2xDUYOZqQ2_gjApifaPO3uG-kzjHpzND3nBD=hzw1TW2A@mail.gmail.com> <20190602130300.ebqbmvhb47r7pdog@faui48f.informatik.uni-erlangen.de> <CAO42Z2z9JkczxvYb09d4Fp7O17nnd0RHjPGnTaG26RPxPVa+Xw@mail.gmail.com> <alpine.DEB.2.20.1906030910010.19892@uplift.swm.pp.se> <19028.1559573360@localhost> <3d99d907-669e-46db-e68b-0a1bdf4a1f89@huitema.net> <18638.1559609425@localhost>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <625b5d9c-7532-4b5f-9e1a-b175092cac1c@gmail.com>
Date: Tue, 04 Jun 2019 15:06:26 +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: <18638.1559609425@localhost>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/kdbGDnhdAimPez7U8IfzCTQSasY>
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, 04 Jun 2019 03:06:33 -0000

On 04-Jun-19 12:50, Michael Richardson wrote:
> 
> Christian Huitema <huitema@huitema.net> wrote:
>     >> Mikael Abrahamsson <swmike@swm.pp.se> wrote:
>     >> >> https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-00
>     >>
>     >> > I have now read RFC1546 and now I understand some of the confusion. Did the
>     >> > concept of "send SYN to anycast address and get SYN-ACK back from actual
>     >> > unicast address" ever get implemented anywhere?
>     >>
>     >> I don't think so.
>     >> Maybe some BSD 4.0 could support it, but it would be fly in the face of most
>     >> firewalls.  It would rely only on the sequence number to match things up.
>     >> That would be pretty weak, particularly at the time RFC1546 was published!
> 
>     > There is support for this kind of behavior in QUIC with the "preferred
>     > address" transport parameter, although it is quite different from what
>     > is stated in RFC1546. From the spec, "QUIC allows servers to accept
>     > connections on one IP address and attempt to transfer these connections
>     > to a more preferred address shortly after the handshake. This is
> 
> That's really cool.
> It's just sad that we have to do it at layer 6 rather than layer 3 :-(

If you think about it, shim6 was really an attempt to do this sort of thing
at layer 3. I never thought of it that way, but shim6 to an anycast address
could trigger an immediate address switch to a unicast address.

I'm not suggesting that this is a practical approach - but it's very close
to a transport-independent solution.

    Brian

> It's nice that we finally have a layer-5 security layer that seems to
> becoming ubiquitous.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

v2.23.0 | Report a Bug | By Email