Re: NAT64 in RA, draft-ietf-6man-ra-pref64

[Mark Andrews <[e-mail]>]

> On 1 Jul 2019, at 2:16 pm, Jen Linkova <[e-mail]> wrote:
> 
> On Fri, Jun 28, 2019 at 3:06 PM Mark Andrews <[e-mail]> wrote:
>>> 1) do we really want to put DNS labels into the router configuration?
>>> NAT64 prefix is smth which is defined and controlled by the routing
>>> infrastructure, while this thing is totally different.
>> 
>> Why not?  DNS labels go in DHCP configurations all the time. What’s the
>> real difference?
> 
> I'd rather avoid it as it would be a nightmare to maintain.

It’s no harder to maintain than anything else.  It would normally just be
the IPv4 prefixes the site is using.  That doesn’t normally change much.

>>> 3) it would *only* work if the application using the APL is also using
>>> the network-provided resolvers - and I can not see how it could be
>>> guaranteed (== it would lead to rather non-obvious failure scenarios
>>> and operational nightmares).
>> 
>> No.  It just requires the OS to record the information where the application
>> can fetch it.  This allows DNS64 processing to be done in getaddrinfo() and
>> not in the DNS servers.
> 
> When you say 'the information' do you mean 'the APL name' or 'the
> prefixes from that APL’?

I would record it as the prefixes with a timer to refetched based on
DNS TTL.  That way the data is available for whatever application wants
it.  RA timers also apply.

>> DNS64 servers are configured with exclusion lists today.  When you
>> move DNS64 processing closer to the application, be it the CPE router, on node,
>> or in app you still need those exclusion lists.  At a minimum you need to
>> exclude ::ffff:0.0.0.0/96 to filter out the mapped addresses published in the
>> DNS.  You also need to exclude the well know DNS64 prefix.  The list only grows
>> from there.
> 
> Oh, so you do not just suggest to keep an list of IPv4 prefixes not to
> translate, but also explicitly specifying a list of IPv6 addresses
> which
> should be ignored when checking for AAAA?
> Well, I disagree that we need to maintain that list. If someone is
> publishing in DNS IPv4-mapped, IPv6-compatible, Link-local,
> Site-local, multicast or whatever crap you can imagine -
> well, good luck. I do not think clients need to work around it.

Well it is specified behaviour of a DNS64 server.  The same list can
return both exclusion lists.

RFC 6147, 5.1.4.  Special Exclusion Set for AAAA Records


   Some IPv6 addresses are not actually usable by IPv6-only hosts.  If
   they are returned to IPv6-only querying agents as AAAA records,
   therefore, the goal of decreasing the number of failure modes will
   not be attained.  Examples include AAAA records with addresses in the
   ::ffff:0:0/96 network, and possibly (depending on the context) AAAA
   records with the site's Pref64::/n or the Well-Known Prefix (see
   below for more about the Well-Known Prefix).  A DNS64 implementation
   SHOULD provide a mechanism to specify IPv6 prefix ranges to be
   treated as though the AAAA containing them were an empty answer.  An
   implementation SHOULD include the ::ffff/96 network in that range by
   default.  Failure to provide this facility will mean that clients
   querying the DNS64 function may not be able to communicate with hosts
   that would be reachable from a dual-stack host.

   When the DNS64 performs its initial AAAA query, if it receives an
   answer with only AAAA records containing addresses in the excluded
   range(s), then it MUST treat the answer as though it were an empty
   answer, and proceed accordingly.  If it receives an answer with at
   least one AAAA record containing an address outside any of the
   excluded range(s), then it by default SHOULD build an answer section
   for a response including only the AAAA record(s) that do not contain
   any of the addresses inside the excluded ranges.  That answer section
   is used in the assembly of a response as detailed in Section 5.4.
   Alternatively, it MAY treat the answer as though it were an empty
   answer, and proceed accordingly.  It MUST NOT return the offending
   AAAA records as part of a response.

>>> Stupid question: why can not we reserve a well-known label (_dns64 ?)
>>> and let the client to request APL in the domains from its search list?
>> 
>> Because there is no requirement to publish a search list and if you are
>> sane you ignore them.  Search list are also badly implemented the same
>> unqualified name to match to different fully qualified names depending
>> upon the query type in the request as search algorithms don’t stop on
>> noerror/nodata and some don’t stop on servfail either.  There is a lot
>> of history behind the behaviour.
> 
> OK, got it, thanks for the explanation.
> 
>> 
>>>>> On 27 Jun 2019, at 8:35 pm, Jen Linkova <[e-mail]> wrote:
>>>>> 
>>>>> Hi Mark,
>>>>> 
>>>>> On Tue, May 28, 2019 at 6:39 AM Mark Andrews <[e-mail]> wrote:
>>>>>> 
>>>>>> The RA optionally includes the name of the APL record.  Inclusion is signalled by the option length.
>>>>> 
>>>>> I'm working on then -01 version of the draft and while trying to
>>>>> incorporate the suggestion you made at the microphone @IETF104, I've
>>>>> realized I'm still confused.
>>>>> 
>>>>> If I got it right, you are suggesting to use the option length to
>>>>> indicate not just the prefix length, but the presence of the APL
>>>>> record, right?
>>>>> So how shall it look like?
>>>>> Are you suggesting to use the Reserved bits to store the APL label length?
>>>>> 
>>>>> Let's look at all possible scenarios:
>>>>> 
>>>>> Scenario 1: /96 prefix, no APL.
>>>>> The option length = 2, the option contains 96 bits of the prefix.
>>>>> 
>>>>> Scenario 2: non-/96 prefix, no APL.
>>>>> The option length = 3, the last 32 bits of the option contains 8 bits
>>>>> of the prefix length + reserved bits.
>>>> 
>>>>> 
>>>>> Scenario3: /96 prefix, APL name exists.
>>>>> The option length is....well, I guess it would depend on the label
>>>>> length, right? So 3 or more.
>>>>> So the first 8 bits after the prefix length would be the APL label
>>>>> length, then the APL (with padding to the 8 octets if needed).
>>>>> 
>>>>> Scenario 4:  non-/96 prefix, APL name exists
>>>>> The same as scenario 3.
>>>>> 
>>>>> My concerns here are:
>>>>> 1) we are making the option parsing quite complicated just to
>>>>> accomodate a hypothetical use case of 'dual-stack network with NAT64';
>>>>> I'm afraid it might slow down the deployment.
>>>> 
>>>>> 2) the state machine is unclear to me:
>>>>> - does the presence of the APL part mean that now the host MUST use
>>>>> the DNS servers provided by the network to resolve the APL (remember,
>>>>> one of the benefit of providing pref64 is ability to remove
>>>>> dependencies on DNS64)? What if the host has DNS servers configured
>>>>> manually? How could the client tell the difference?
>>>>> 
>>>>> So far I'm still not convinced that it's worth doing (at least currently).
>>>>> If anything, I'd say the APL information should be in RDNSS option as
>>>>> it shares fate with the DNS.
>>>>> 
>>>>> Or am I missing smth/misunderstood your suggestion?
>>>>> 
>>>>>>> On 28 May 2019, at 06:29, Mark Andrews <[e-mail]> wrote:
>>>>>>> 
>>>>>>> You use  an APL record to define which addresses are mapped/excluded  (the difference is where the negations goes and whether you include the /0 entries at the end normally) on a first match basis.
>>>>>>> 
>>>>>>> e.g.
>>>>>>> 
>>>>>>> APL !1:10.0.0.0/8 1:0.0.0.0/0
>>>>>>> 
>>>>>>> Not net 10 but everything else.
>>>>>>> 
>>>>>>> TYPE42 \#9 00 01 08 81 0a 00 01 00 00
>>>>>>> 
>>>>>>> The above is a mapping list not a exclude list.
>>>>>>> 
>>>>>>> You can also encode the IPv6 prefixes you want to ignore when determining if you are doing.  This is useful for when you want to be IPv6 internally but don’t have external connectivity  or you only have partial IPv6 connectivity or for ignoring the results of a seperate DNS64 mapping.
>>>>>>> 
>>>>>>> Both lists can be encoded in a single APL record. Also it is easy enough to encode the record in unknown record format by hand as the encoding is not hard to do.  See above.
>>>>>>> 
>>>>>>> --
>>>>>>> Mark Andrews
>>>>>>> 
>>>>>>>> On 28 May 2019, at 01:57, Michael Richardson <[e-mail]> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I just watched the 6man recording on draft-ietf-6man-ra-pref64.
>>>>>>>> I am very enthusiastic about having this progress, because it enables DNSSEC
>>>>>>>> resolution to be done on the host.
>>>>>>>> (We just have to find a way in CAPPORT to shame
>>>>>>>> 
>>>>>>>> The document says:
>>>>>>>> 
>>>>>>>> In a network that provides both IPv4 and NAT64, it may be desirable
>>>>>>>> for certain IPv4 addresses not to be translated.  An example might be
>>>>>>>> private address ranges that are local to the network and should not
>>>>>>>> be reached through the NAT64.  This type of configuration cannot be
>>>>>>>> conveyed to hosts using this option, or through other NAT64 prefix
>>>>>>>> provisioning mechanisms such as [RFC7050] or [RFC7225].  This problem
>>>>>>>> does not apply in IPv6-only networks, because in such networks, the
>>>>>>>> host does not have an IPv4 address and cannot reach any IPv4
>>>>>>>> destinations without the NAT64.
>>>>>>>> 
>>>>>>>> And I guess I disagree with this in a subtle way, which Section 7
>>>>>>>> (multihoming) tries to deal with.   Maybe you could write:
>>>>>>>> 
>>>>>>>> In a provisioning domain that provides both IPv4 and NAT64, it may be desirable
>>>>>>>> for certain IPv4 addresses not to be translated.  An example might be
>>>>>>>> private address ranges that are local to the provisioning domain and should not
>>>>>>>> be reached through the NAT64.  This type of configuration cannot be
>>>>>>>> conveyed to hosts using this option, or through other NAT64 prefix
>>>>>>>> provisioning mechanisms such as [RFC7050] or [RFC7225].  This problem
>>>>>>>> does not apply to hosts that are provisioned in IPv6-only networks,
>>>>>>>> because in such networks, the host does not have an IPv4 address and
>>>>>>>> cannot reach any IPv4 destinations without the NAT64.
>>>>>>>> Section 7 deals with the multihoming sitution more.
>>>>>>>> 
>>>>>>>> ----
>>>>>>>> 
>>>>>>>> The slides had some optional stuff which I think is gone from the document.
>>>>>>>> Mark Andrews made some suggestions, which I did not understand what happened.
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Michael Richardson <[e-mail]>, Sandelman Software Works
>>>>>>>> -= IPv6 IoT consulting =-
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> --------------------------------------------------------------------
>>>>>>>> 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
>>>>>>> --------------------------------------------------------------------
>>>>>> 
>>>>>> --------------------------------------------------------------------
>>>>>> IETF IPv6 working group mailing list
>>>>>> [e-mail]
>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>> --------------------------------------------------------------------
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> SY, Jen Linkova aka Furry
>>>> 
>>>> --
>>>> Mark Andrews, ISC
>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>> PHONE: [phone]              INTERNET: [e-mail]
>>>> 
>>> 
>>> 
>>> --
>>> SY, Jen Linkova aka Furry
>> 
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: [phone]              INTERNET: [e-mail]
>> 
> 
> 
> -- 
> SY, Jen Linkova aka Furry

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]