[v6ops] draft-ietf-v6ops-ipv6-only-resolver AFI Preference

Tobias Fiebig <tobias@fiebig.nl> Sun, 05 November 2023 09:55 UTC

Message-ID: <11d936bdc519e6fcce23ef02ff3469b5831943f3.camel@fiebig.nl>
From: Tobias Fiebig <tobias@fiebig.nl>
Reply-To: tobias@fiebig.nl
To: v6ops@ietf.org
Cc: dnsop <dnsop@ietf.org>, "momoka.my6" <momoka.my6@gmail.com>
Date: Sun, 05 Nov 2023 10:55:40 +0100
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/4lwr-JvjBMaCQ38Tm6Ogfasxs_o>
Subject: [v6ops] draft-ietf-v6ops-ipv6-only-resolver AFI Preference
Precedence: list

Moin,

during the hackathon i gave setting up Unbound 1.18.0 (which implements
the draft already [1]) a shot with Momoka (2a06:d1c7:: if anyone wants
to try; Some ratelimiting present), and we also replayed a couple of DS
zones to resolve the question if 'prefer-ip6: yes' should be set [2].

The observation is that unbound in the current implementation actually
does do happy eyeballs with nat64, i.e., without 'prefer-ip6: yes'
there are indeed queries for v6 capable authoritative servers handled
via nat64 instead of via native IPv6.

I think this opens an interesting can of worms; RFC8305 in not really
(BCP14 level) clear on the matter (other than indicated in [3]); This
is essentially for cases where a client wants to connect to a v4
literal and SHOULD then perform translation; The AUTHNS part does not
use authoritative language.

However, the issue with Unbound (I'd argue) is that the part that does
the HE decision is independent of the part that then does nat64, i.e.,
the HE part assumes v4 connectivity, and does normal HE; However, v6
should be preferred as v6 will not have to go through a transition
mechanism; I see some perspectives on this that could range this in the
area of 'implementation case' though.

All being said, i personally see three options for handling this:

- Accept that NAT64 (also with literals) with HE and DS may lead to 
  hosts being contacted via a transition technique even though a 
  native AFI path is available.
- Put a SHOULD/SUGGESTED into draft-ietf-v6ops-ipv6-only-resolver to 
  only use this with 'prefer-ip6: yes' (or similar depending on the 
  implementation.
- Think about touching RFC8305; _Technically_ the point above is 
  already in RFC8305:

   "If a DNS server is configured to be accessible over IPv6, IPv6 
    should be assumed to be the preferred address family."

  So, technically, making that should <bcp14>SHOULD</bcp14> would
  essentially solve the point above.
  
  Going a bit further, Sec. 7 could be amended to explicitly state that
  in cases where NAT64/Other TT are used, IPv6 SHOULD be preferred...
  but writing this feels like something far to likely of having
  overlooked far too many corner cases and earlier discussions.

With best regards,
Tobias

[1] 
https://github.com/NLnetLabs/unbound/pull/722
[2] 
https://github.com/NLnetLabs/unbound/pull/722#issuecomment-1497488164
[3] 
https://github.com/NLnetLabs/unbound/pull/722#issuecomment-1497823690

-- 
Dr.-Ing. Tobias Fiebig
T +31 616 80 98 99
M tobias@fiebig.nl

[v6ops] draft-ietf-v6ops-ipv6-only-resolver AFI P… Tobias Fiebig