Re: IPv6 only host NAT64 requirements?

[Fred Baker <[e-mail]>]

Tore Anderson has a multiple prefix installation.

Sent using a machine that autocorrects in interesting ways...

> On Nov 17, 2017, at 4:30 PM, Jen Linkova <[e-mail]> wrote:
> 
> On Thu, Nov 16, 2017 at 12:35 AM,  <[e-mail]> wrote:
>>> IMHO the optimal solution is:
>>> - the network SHOULD provide a host with NAT64 prefix information in
>>> RA (I do not believe that information needs to be duplicated in DHCP
>>> at all);
>> 
>> [Med] Please check: https://tools.ietf.org/html/rfc7051#section-5.7.3
> 
> Thanks for pointing this out. To be honest I disagree with what that
> section says.
> I'm trying to refrain from participating  'SLAAC vs DHCPv6' so I will
> not mention all those issues with multihoming for example but....
> If you are saying that the prefix should not be distributed via RAs
> because it needs to be configured on routers, then what about DNS
> servers and SLAAC prefixes themselves?
> There are SLAAC-only networks out there while RFC7934 does not
> recommend DHCPv6 as the only way to configure clients.
> So between those two RA does look like a better way.
> 
>> Things may get complex if multiple NSPs are used for load-balancing or if destination based NAT64s are deployed. A list of issues is elaborated in https://tools.ietf.org/html/rfc7225#section-3.1
> 
> It's more like v6ops question but I'm really curious if multiple
> prefixes scenario is real.
> RA option might contain multiple prefixes anyway.
> 
>>>>> 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
>>>> --------------------------------------------------------------------
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> SY, Jen Linkova aka Furry
>>> 
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
> 
> 
> 
> -- 
> SY, Jen Linkova aka Furry
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------