Subject: Re: [v6ops] AWS ipv6-only features

From: Nick Buraglio <[email-masked]>
Date: Wed, 1 Dec 2021 13:46:18 -0600

On Tue, Nov 30, 2021 at 1:57 PM Brian E Carpenter <
[email-masked]> wrote:

> On 01-Dec-21 06:14, Owen DeLong wrote:
> >
> >
> >> On Nov 30, 2021, at 01:47 , Philip Homburg <[email-masked]>
> wrote:
> >>
> >>>    On Nov 29, 2021, at 10:33 , Nick Buraglio <[1][email-masked]>
> >>>    wrote:
> >>>
> >>>    "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."
> >>>
> >>>    Yep... The moral of the story is that GUA works as intended and
> >>>    ULA is a bit of a mess.
> >>
> >> I'm a bit confused about this scenario.
> >>
> >> Typically a hosts gets addresses from DNS. So this suggests that people
> >> create DNS RR sets that contains both GUAs and ULAs.
> >>
> >> Is this common practice somewhere? Do people expect that something
> sensible
> >> will happen if you try that? Is it documented what should happen?
> >
> > Probably more common in mDNS than DNS, but yes, something sensible SHOULD
> > happen as documented in the RFCs:
> >
> > AAAA record sorting in getaddrinfo() or getnameinfo() should return the
> ULA records
> > before the GUA records in the linked list.
>
> That should be an application programmer's choice, I think, because whether
> ULAs should be preferred is an application-specific choice. In some cases,
> a "happy eyeballs" heuristic might even be best. In any case, I don't see
> how the IETF can design a one-size-fits-all solution.
>
> Also, of course, there are choices like: does a printer need a GUA? Why
> wouldn't a ULA be sufficient? The same goes for any internal-use-only
> server.
>
> Also a site could decide not only to use split-horizon DNS, but also
> to use different DNS names for different addresses, e.g.
> [email-masked] for the ULA and [email-masked]
> for the GUA.
>
> We abandoned draft-ietf-v6ops-ula-usage-recommendations and
> draft-ietf-v6ops-ula-usage-considerations. Maybe it's time to restart such
> an effort.
>

That, at least, would be something. Whether we like it or not, ULA is a
current, active technology. Making operational IPv6 easier to understand,
deploy, and support should be a direct result of the work produced.

>
>     Brian
>
> >
> > As a result, an application that sensibly iterates through the list in
> order (as is expected
> > behavior) should connect via GUA if possible (if not, it should rapidly
> receive an error
> > and move on to the next item in the list, so no extraordinary processing
> or coding
> > is required in the application).
>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Nick Buraglio <[email-masked]>
Date: Wed, 1 Dec 2021 13:58:01 -0600

On Wed, Dec 1, 2021 at 12:36 AM Philip Homburg <[email-masked]>
wrote:

> > Probably more common in mDNS than DNS, but yes, something sensible
> > SHOULD happen as documented in the RFCs:
> >
> > AAAA record sorting in getaddrinfo() or getnameinfo() should return
> > the ULA records before the GUA records in the linked list.
> >
> > As a result, an application that sensibly iterates through the list
> > in order (as is expected behavior) should connect via GUA if possible
> > (if not, it should rapidly receive an error and move on to the next
> > item in the list, so no extraordinary processing or coding is
> > required in the application).
>
> mDNS is a bit of a boring case. If you get an mDNS reply is likely that the
> destination is on the same subnet. It is possible to mess that up, but
> that is more upto the network admin.
>

As is having multiple AAAA records for different addresses. I've definitely
seen this with GUA.

> With DNS, how is it sensible to put both a ULA and a GUA in a single
> DNS record?  Without happy eyeballs (and anything that is not
> a webbrowser is unlikely to implement happy eyeballs), putting in two
> addresses for a host just means waiting twice as long when the host is
> down.
>

If a host is down then the timeout doesn't matter. If a protocol is broken,
without happy eyeballs then failover is already long enough that the user
has likely moved on.  But how does that work for other services? Anything
without happy eyeballs has a timeout long enough that the user will see it
and almost certainly move on or report a problem. More savvy users may wait
it out or try to figure out why their SSH session times out or the like, at
which point it largely doesn't matter what the actual problem is. It's a
degraded service. Having best practices in place on top of reference
designs would go a long way. Personally, I think being prescriptive in the
preference order is warranted. If an application fails to heed that, then
there is a document to point to that says "this, then that, then this" will
save a lot of headaches for both developers that are blindly making up
their own rules (as they would have guidelines to reference) and folks
operating a network or support an application stack that have to answer the
phone.

>
> What benefit do you expect to get from putting two addresses for the same
> host in DNS (at the same DNS name, in the same view)?
>

This is obviously very common with IPv4 and IPv6 - www.google.com resolves
to both the same A and AAAA, what is the functional difference? I can do
the same thing with my RFC1918 space internally (or externally , regardless
of "correctness", if I am so inclined). Granted, DNS views are the
technically smartest choice here, however, the question is not "why would
someone do it this way?". That operational ship sailed years ago with the
advent of the ULA RFC and is comfortably adrift at sea And it's not
changing until enough momentum is in place to tow it back - which is also
not really the point. The question is, operationally, why does this behave
inconsistently? Sure, it's up to the application developers. What guidance
do they have? Our answer to that question should absolutely *not* be
"developers don't understand networks". While often true, that is a
response to a completely different problem space doesn't make anyones
production deployment or on-call schedule any better.
The question we should be asking is "Can we improve this? How?" Be it
guidelines as Brian suggested, or other mechanisms, someone should be
asking, so I am. I am happy to answer as well.

> Having two views (or names), one for external use with a GUA and one
> internal
> use with ULA makes sense.
>

Sure, that's a best case deployment. How many first time IPv6 deployments
fall into that category? Not many. My first few 15+ years ago were
admittedly a total disaster and were re-done after we learned some hard
lessons.
I am getting asked about things like ULA, documentation space, and
other foundational IPv6 concepts a lot in recent months. With the
increasing push for IPv6 (and IPv6-only) the questions won't get any
fewer.  The more consistently those of us prototyping, designing, building,
and supporting IPv6 can answer, the higher the tide raising all boats will
be.

I will now step off of my high horse, the air is getting a bit thin up
here.

nb