[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: [IPv6] Developing a solution to a problem that shouldn't exist (Re: ULA vs. 1918)
From:       Brian E Carpenter <brian.e.carpenter () gmail ! com>
Date:       2023-06-21 22:15:21
Message-ID: 9d79f697-22a2-bb42-5a55-b47877ee9238 () gmail ! com
[Download RAW message or body]

On 22-Jun-23 09:00, Kyle Rose wrote:
> On Wed, Jun 21, 2023 at 1:38 PM David Farmer <farmer@umn.edu \
> <mailto:farmer@umn.edu>> wrote: 
> Do we expect them to use IPv6 literals instead of DNS names for ULAs? 
> 
> 
> There is such a thing as split-horizon DNS. It's very common to have DNS servers \
> that serve classes of response only to clients that are a priori supposed to have \
> access to the target system. My use case is one such. 
> I don't think the problem is ULA in the DNS.
> 
> 
> It's *a* problem that should be solved (if you mean public DNS, as I assume you \
> do). But I don't think we need to eliminate those kinds of configuration errors to \
> increase the utility of ULA: simply preferring GUA dests to ULA when both are \
> present (say via a precedence of 39 for fc00::/7) but not to IPv4 (precedence 35), \
> and continuing to prefer GUA->GUA or IPv4->IPv4 over ULA->GUA (already the case via \
> the higher-order label match) would achieve my goal of making ULA useful in \
> dual-stack contexts while not breaking/slowing dual-stack client access to \
> dual-stack sites that mistakenly leak ULA addresses to public DNS alongside GUA and \
> IPv4. 
> The one case this approach makes worse is a site that mistakenly exposes only ULAs \
> alongside IPv4 addresses, in which case a client with a ULA would observe that \
> breakage/slowness on initial connection attempts, necessitating something like HE. \
> (My firewalls ICMPv6-reject attempts to reach the internet with a ULA source \
> address, so the client gets immediate feedback, mitigating the issue in the \
> presence of HE.) 
> I think the problem is having both ULA and GUA addresses associated with the same \
> name. 
> 
> If GUA dests are preferred, the ULA addresses are probably vestigial for most IPv6 \
> clients (because they will also have a GUA and will therefore prefer the GUA dest). \
> So under that regime, there's not much of a point in having the same name resolve \
> to both GUA and ULA within a particular DNS horizon. If they're both on the same \
> footing (say, both precedence 40), then you run into more cases of breakage when \
> ULA addresses are leaked. 
> This far into the thread and with a week of reflection, I guess I would argue for \
> putting functionality for dealing with misconfigurations purely on the HE side of \
> the HE/address selection divide. HE should be responsible for mitigations that \
> allow a client to connect to a server in the presence of partial brokenness, \
> whether on the part of the client or the server or some piece of infrastructure in \
> the middle: that's why it exists. The explicit 6724 precedence of IPv4 over ULA in \
> destination address selection seemingly exists only to deal with this class of \
> misconfiguration, and should instead be relegated to HE. In that sense, I'd be \
> happy with a ULA precedence of either 39 or 40. My Debian systems, including my \
> desktop, have had ULA at 40 for years via the gai.conf maintainer never "upgrading" \
> the policy table from 3484 to 6724, and I haven't encountered any significant \
> issues.

Right. So we need to fix RFC6724, and I am confident there will be a draft Real Soon \
Now. To be clear, there are at least three mitigations, *all of which* are needed:

1. Fix RFC6724.

2. Recommend a sensible DNS naming practice, including split-horizon DNS.

3. Design a dynamic, probing based generic "happy eyeballs" solution. We can have a \
good long argument whether that is better done in the kernel stack or in QUIC.

I'd say we can do #1 quickly in this WG, but #2 and #3 will take a lot more time and \
need discussion much more widely than just this WG.

     Brian

P.S. Just to add another complication to the story, please be aware that ULAs also \
interact with the CORS (cross-origin resource sharing) issue under debate in the W3C \
community at https://wicg.github.io/private-network-access/ .

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


[prev in list] [next in list] [prev in thread] [next in thread]