Re: [v6ops] AWS ipv6-only features

[Nick Buraglio <[e-mail]>]

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

> > > 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.
> >
> > 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



>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>