Re: IPv6 only host NAT64 requirements?

[Ca By <[e-mail]>]

On Tue, Nov 14, 2017 at 6:08 PM Ole Troan <[e-mail]> wrote:

> Mark,
>
> Thanks for doing the analysis of this. It will take me some time to digest.
>
> If I may try to suggest a solution based on what you are saying:
>
> - Remove (external) DNS64 from the solution
> - Replace NAT64 prefix discovery with some sort of local configuration.
> e.g. put it in DHCP or RA
>
> Which has the implications that:
>  - host learns NAT64 prefix via RA/DHCP
>  - host is free to use whatever DNS recursive resolvers (instead of the
> must be local (and on correct interface where the NAT64 is) resolver
>  - host synthesises addresses itself. And does validation before
> synthesising (if that's required).
>
> Is this the solution you would be looking for?
>
> And yes, you need host changes. But we need that anyway.
>

Or your peer node could deploy ipv6 and be done with all these transition
nonsense.

As has been reported in elsewhere, docsis and 3gpp networks see 50+ and
70+% of their bits moved to ipv6.   The problem size is waning quickly,
especially on modern OS


> Cheers,
> Ole
>
>
>
>
> > On 15 Nov 2017, at 08:06, Mark Andrews <[e-mail]> wrote:
> >
> >
> >> On 15 Nov 2017, at 3:40 am, Lorenzo Colitti <[e-mail]> wrote:
> >>
> >> On Tue, Nov 14, 2017 at 6:46 AM, Mark Andrews <[e-mail]> wrote:
> >> Is there any reason to run DNS64 at all these days?  ipv4only.arpa can
> be a preconfigured
> >> zone which allows CLAT to get its mapping.  All the phones have CLAT
> support.
> >>
> >> That's an interesting idea. It would work in theory, but such a network
> would completely break devices that don't support 464xlat. That gives up
> one of the major advantages of NAT64/DNS64, which is that it's a 90%
> solution even just by itself - yes, IPv4-only applications and address
> literals exist, but most simple client/server applications Just Work behind
> it.
> >
> > And that 90% “solution” has lots of down sides.  It basically requires
> EVERY DNS VALIDATOR ON
> > THE PLANET TO SUPPORT DNS64 JUST IN CASE IT IS USED BEHIND A DNS64
> SERVER.
> >
> > DNS64/NAT64 was presented as NOT REQUIRING node changes when first
> mooted.  It keeps on
> > requiring more and more highly invasive node changes to support.  It was
> from the very beginning
> > bad engineering.   To get IPv4 as a service some node changes are
> required.  Lets make sure they
> > are MINIMAL ones.
> >
> > Just for the record DNSSEC validators need to send BOTH CD=0 and CD=1
> queries to get answers
> > though a upstream VALIDATING server which includes a VALIDATING DNS64
> server as CD=0 and
> > CD=1 address different DNSSEC threats.  I tried very hard to point that
> out when RFC 6147 was
> > being written but the working group decide that CD indicated whether the
> client was validating or
> > not.  There is NO SUCH INDICATION in a DNS message.
> >
> >  If a query arrives at a vDNS64 device with the "Checking Disabled"
> >   (CD) bit set, it is an indication that the querying agent wants all
> >   the validation data so it can do checking itself.  By local policy,
> >   vDNS64 could still validate, but it must return all data to the
> >   querying agent anyway.
> >
> > CD=0 queries causes the upstream validating servers to reject incoming
> spoofed answers
> > or stale answers (this is a common operational problem).
> >
> > CD=1 queries allow the validation to succeed when the upstream validator
> has a bad trust
> > anchor or a bad clock which is rejecting legitimate answers.
> >
> > A validating client can’t just send CD=1 queries as the upstream
> validator doesn’t kick in.
> > The upstream validator can lock onto a stale answer source.  It needs to
> send CD=0 queries
> > on validation failure to force the upstream validator to try multiple
> sources.
> >
> > A validating client can’t just send CD=0.  It needs to send CD=1 on
> SERVFAIL in case the
> > upstream validator has a bad trust anchor (likely with the upcoming root
> KSK roll) or has
> > a bad clock (these usually get fixed fast).
> >
> > Now to get a answer from a signed zone with servers with stale answers a
> validatiing DNS64 client
> > needs to send:
> >
> > a) send CD=1 and validation failure send CD=0 then on AAAA validation
> failure send CD=1 and
> >    hope the TTL was not 0 and that is not cachable and there is no
> assurance that you won’t get
> >    a answer from a stale source.
> >
> >       or
> >
> > b) send CD=0 and on validation failure of the AAAA send CD=1 and hope
> the TTL was not 0 as
> >    that is not cachable and there is no assurance that you won’t get a
> answer from a stale source.
> >
> > TTL=0 answers exist.
> >
> > Note none of this is documented in a RFC.  You have to understand how
> both DNSSEC and DNS64 work to
> > realise this.
> >
> > IPV4ONLY.ARPA is currently has a secure delegation which breaks prefix
> discover for DNS VALIDATORS.
> > Note “ad” is set in the flags.  Yes, I’ve submitted a errata.  Yes, I’ve
> opened a ticket to get it fixed but
> > based on past experience that could take months if it happens at all.
> You will note that the recursive
> > server is running on the loopback interface so all DNS answers are being
> validated here.
> >
> > [rock:bind9/bin/named] marka% dig IPV4ONLY.ARPA
> > ;; BADCOOKIE, retrying.
> >
> > ; <<>> DiG 9.12.0b2+hotspot+add-prefetch+marka <<>> IPV4ONLY.ARPA
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8504
> > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ; COOKIE: 7dbf8beb79be47a09eb5313d5a0b776f4fae3aa6931d9583 (good)
> > ;; QUESTION SECTION:
> > ;IPV4ONLY.ARPA.                       IN      A
> >
> > ;; ANSWER SECTION:
> > ipv4only.arpa.                26574   IN      A       192.0.0.171
> > ipv4only.arpa.                26574   IN      A       192.0.0.170
> >
> > ;; Query time: 0 msec
> > ;; SERVER: 127.0.0.1#53(127.0.0.1)
> > ;; WHEN: Wed Nov 15 10:08:31 AEDT 2017
> > ;; MSG SIZE  rcvd: 115
> >
> > [rock:bind9/bin/named] marka%
> >
> >> It's not true that all phones have clat support. Notably, Apple not
> only does not support it but appears ideologically opposed to it on the
> grounds that it does not have a good exit strategy (because it makes it
> possible to run IPv4-only apps forever).
> >
> >
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: [phone]              INTERNET: [e-mail]
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>