Re: [v6ops] AWS ipv6-only features

On Mon, Nov 29, 2021 at 3:06 PM Brian E Carpenter <
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,
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>> 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
> > https://www.ietf.org/mailman/listinfo/v6ops
> >
>
>