Re: [v6ops] AWS ipv6-only features

Hi Nick,
Thanks for the discovery.
ULA has a few purposes. What you have disclosed defeats stability purpose (probably, the primary ULA purpose).
If the internal session is initiated on GUA, but GUA is correctly reclaimed (and deprecated) later then the session is interrupted
despite ULA being available to avoid interruption.

It effectively makes low value for all recommendations of RFC 7084 on ULA.
And the same problem for all other cases when ULA has been used for stability (like Homenet).

IMHO: It is the big problem. It is bigger than filtered EHs on the Internet.
How is it possible to fix it?

Eduard
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Nick Buraglio
Sent: Tuesday, November 30, 2021 12:45 AM
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] AWS ipv6-only features

On Mon, Nov 29, 2021 at 3:06 PM Brian E Carpenter <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>> wrote:
Nick,

On 30-Nov-21 07:33, Nick Buraglio 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:
>
> /"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).

Please be more precise about the scenario. Do you mean that both hosts have AAAA records for their GUAs *and* ULAs, and that the app uses DNS names, or what?

In the testing I was performing to double check my notes I had this scenario:

host 1 (linux, A for IPv4, AAAA for IPv6 GUA, AAAA for IPv6 ULA)
host 1 (linux, A for IPv4, AAAA for IPv6 GUA, AAAA for IPv6 ULA)
host 1 (MacOS 12.0.1, A for IPv4, AAAA for IPv6 GUA, AAAA for IPv6 ULA)
RouterOS based router 1 (RouterOS, A for IPv4, AAAA for IPv6 GUA, AAAA for IPv6 ULA) - RouterOS seems to default to IPv4 for some dumb reason, even when the source address is set to v6
All A and AAAA records match their respective hosts (i.e. host1.lab.int<http://host1.lab.int>, host2.lab.int<http://host2.lab.int>, etc.)

In each case when I attempt to reach the devices I use the DNS record the default is to the GUA, from the GUA, with the exception of Mikrotik which by default uses IPv4 if it exists as an A record, even if specifying an IPv6 src address.

Nevertheless, default address selection in RFC6724 is that GUAs win over ULAs, so what you report is correct out-of-the-box behaviour. The description in Mark's blog is not the default scenario, but you could make it true by changing the RFC6724 policy table in all your hosts.

If an individual app *wants* to prefer ULAs, it's not hard, but it does have to be an explicit choice. (My implementation of GRASP, for example, explicitly picks ULA over GUA if both are available, and reverts to link-local if neither is available.)

Understood.

> 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.
>
> Seemingly relevant to the discussion at hand, and definitely relevant to enterprises and providers actively using or considering ULA.

The default in RFC6724 was chosen precisely to avoid surprises for enterprises and providers. If you want ULAs as the default preference, you have
to change something.

Right, which is functionally impossible for most commercial platforms meaning it generally doesn't happen so get consistent behavior of ULA being deprioritized.

     Brian

>
> nb
>
> On Thu, Nov 25, 2021 at 2:49 PM Mark Smith <markzzzsmith@gmail.com<mailto:markzzzsmith@gmail.com> <mailto:markzzzsmith@gmail.com<mailto:markzzzsmith@gmail.com>>> wrote:
>
>
>
>     On Fri, 26 Nov 2021, 07:41 Clark Gaylord, <cgaylord@vt.edu<mailto:cgaylord@vt.edu> <mailto: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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
>