Re: [v6ops] AWS ipv6-only features

Owen DeLong <owen@delong.com> Mon, 29 November 2021 21:27 UTC

Return-Path: <owen@delong.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FECE3A0060 for <v6ops@ietfa.amsl.com>; Mon, 29 Nov 2021 13:27:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=delong.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 1MNITisAQ830 for <v6ops@ietfa.amsl.com>; Mon, 29 Nov 2021 13:27:19 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 53A893A0044 for <v6ops@ietf.org>; Mon, 29 Nov 2021 13:27:19 -0800 (PST)
Received: from smtpclient.apple ([IPv6:2620:0:930:0:3c9f:a5b:5545:5a54]) (authenticated bits=0) by owen.delong.com (8.16.1/8.15.2) with ESMTPSA id 1ATLRG1W1279974 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 29 Nov 2021 13:27:16 -0800
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 1ATLRG1W1279974
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1638221236; bh=N4FxnEJ37xl10rT+2zWISBr9XaAIPeAPbpf6MVQFh8U=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=DQGGGQ6BQS2zUuLGvW2HlkcRHeLbMXSX0lrt0wGFerehAEX9hit7bqOjEZq24vDu4 C7S8PcyJj4JDZWjCjkTqguD939NqVX3PGBBczhU3YkT/aBQnldSxx47FnXJIDw0ziV 5ywB5CC24Kk7R2GxU5xTGays3nFmGAbcnJOhGTaM=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <4be70dc4-2e5e-93b2-e27f-73700b6c9400@gmail.com>
Date: Mon, 29 Nov 2021 13:27:16 -0800
Cc: v6ops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <5BBB5DB7-FD85-4ED4-A31E-7EB1926449DC@delong.com>
References: <CAD6AjGRAkpMDaAh31mVL=+Gcz5PHejUxxLazr4Xb=vVRHfaSpw@mail.gmail.com> <CAO42Z2z8u_DQMd9eNSQp_RhBinXk2KyH4pdbVLMEqOta-hoG1w@mail.gmail.com> <CADzU5g5odQ82FJ0TsdNxFB42OkgLZ+PWanLLrK1roLojAUS54A@mail.gmail.com> <CAO42Z2z+ZJ_pLwZmBjZ_HFsNXQ6jok-PMRTP23ZD2UMch61wtw@mail.gmail.com> <CAM5+tA9JhRWfZ2VLLQnT8Mg+Xng-+Rc-oQnX8Ma5DguL2uDO8w@mail.gmail.com> <C7A86994-311E-4D94-80AE-74A15D6D62B1@delong.com> <4be70dc4-2e5e-93b2-e27f-73700b6c9400@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.4 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Mon, 29 Nov 2021 13:27:16 -0800 (PST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/X1ZPnPChJ0KnuTdQR24zOx6UQnA>
Subject: Re: [v6ops] AWS ipv6-only features
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Nov 2021 21:27:24 -0000


> On Nov 29, 2021, at 13:10 , Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> On 30-Nov-21 09:05, Owen DeLong wrote:
>>> On Nov 29, 2021, at 10:33 , Nick Buraglio <buraglio@es.net <mailto:buraglio@es.net>> wrote:
>>> 
>>> Thank you for writing some information on ULA, it's an important part of IPv6 and not really discussed enough. Perhaps we should start another thread, but I'd like to hear more about when you see this behavior: 
>> We can agree to disagree on its importance.
>>> /"ULAs are preferred over GUAs, so when a host is presented with both a ULA and GUA as possible ways to reach a destination, the host will select the ULA. Once the ULA destination address is chosen, the host will then choose its ULA as a source address to reach the ULA destination. This preference of ULA addressing over GUA addressing is the mechanism that provides internal network connectivity independence from concurrent external 
> Internet connectivity."/
>>> 
>>> In testing and in practice I have experienced that exactly the opposite of this is true in both day-to-day use and every single explicit test I 
> have done where ULA and GUA are present on both sides with a variety of hardware platforms and operating systems. GUA is used in every scenario I test when the AAAA records are all matching (i.e. appropriately correct DNS). I'm happy to learn that I am incorrect, as it would make certain things easier, but nothing so far in my experience has shown the described behavior.
>>> 
>>> 
>> The quote is from the RFCs, but implementors often do differently. It is not surprising that ULA is an absolute cock-up… I predicted as much when it was being discussed in the IETF. It’s one of the reasons I opposed ULA in general, but most especially the idea of ULA Coordinated.
>>> Seemingly relevant to the discussion at hand, and definitely relevant to enterprises and providers actively using or considering ULA. 
>> Yep… The moral of the story is that GUA works as intended and ULA is a bit of a mess.
> 
> I disagree. ULAs work fine for their intended purpose. That purpose is not "Net 10 for IPv6."

Brian, the difference between theory and practice is that in theory, there is no difference.

So, you are correct that as documented, ULAs could be made to work fine for their intended purpose.

In reality, implementations differ widely and almost none of the most widely deployed implementations match the RFCs well enough
to fit your claim here.

As such, in practice, ULA is a bit of a mess.

Owen

> 
>   Brian
> 
>> Owen
>>> 
>>> nb
>>> 
>>> On Thu, Nov 25, 2021 at 2:49 PM Mark Smith <markzzzsmith@gmail.com <mailto:markzzzsmith@gmail.com>> wrote:
>>> 
>>> 
>>> 
>>>    On Fri, 26 Nov 2021, 07:41 Clark Gaylord, <cgaylord@vt.edu <mailto:cgaylord@vt.edu>> wrote:
>>> 
>>>        Yeah AWS hold their cards close and don't seem to engage the community, but they do have decent IPv6 coverage across the services. Notwithstanding that the whole VPC concept has the whiff of ancient days about it; tonight we're gonna network like it's 1999!
>>> 
>>>        EC2 as part of the address is a great idea. I am so stealing that (can't believe I haven't thought of it.)
>>> 
>>> 
>>>    It's a terrible idea. The "Unique" in ULA is on purpose.
>>> 
>>> 
>>>      Getting IPv6 private addressing right
>>> 
>>>    https://blog.apnic.net/2020/05/20/getting-ipv6-private-addressing-right/ <https://blog.apnic.net/2020/05/20/getting-ipv6-private-addressing-right/>
>>> 
>>> 
>>> 
>>>        On Thu, Nov 25, 2021, 15:09 Mark Smith <markzzzsmith@gmail.com 
> <mailto:markzzzsmith@gmail.com>> wrote:
>>> 
>>> 
>>> 
>>>            On Thu, 25 Nov 2021, 23:51 Ca By, <cb.list6@gmail.com <mailto:cb.list6@gmail.com>> wrote:
>>> 
>>>                Fyi, aws has gone beyond perfunctory ipv6 support and has released a series of enhancements, with a focus on ipv6-only scenarios, including nat64 / dns64
>>> 
>>>                https://aws.amazon.com/about-aws/whats-new/2021/11/aws-nat64-dns64-communication-ipv6-ipv4-services/ <https://aws.amazon.com/about-aws/whats-new/2021/11/aws-nat64-dns64-communication-ipv6-ipv4-services/>
>>> 
>>>                AWS has lapped Google and Azure in advanced network features, which is really surprising given the early muscle Google developed at IPv6 launch and a stronger need to differentiate … 
>>> 
>>>            AWS failed to do ULAs properly. 'ec2' could be a random global ID, but unlikely when their service is "EC2".
>>> 
>>>            Matters more here because they're exposing that to all of their tenants. I think GUAs would have been better for these internal all 
> tenant services.
>>> 
>>>            I've never seen AWS participate here in 20 years, unlike G 
> and M.
>>> 
>>> 
>>>                _______________________________________________
>>>                v6ops mailing list
>>>                v6ops@ietf.org <mailto:v6ops@ietf.org>
>>>                https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
>>> 
>>>            _______________________________________________
>>>            v6ops mailing list
>>>            v6ops@ietf.org <mailto:v6ops@ietf.org>
>>>            https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
>>> 
>>>    _______________________________________________
>>>    v6ops mailing list
>>>    v6ops@ietf.org <mailto:v6ops@ietf.org>
>>>    https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
>>> 
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org <mailto:v6ops@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/v6ops
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops