Subject: DNS64 pref option.

From: Mark Andrews <[email-masked]>
Date: Tue, 6 Nov 2018 19:19:58 +1100

I want a option to be able to configure name servers that do DNS64 inside a network with local dual stack.  This requires knowing what IPv4 addresses are not to be translated and which IPv6 addresses to ignore and perform DNS64 synthesis on the IPv4 address.  Both of these ACLs can be provided at a single name with a APL record.

For CLAT you effectively get this because you don’t route local IPv4 traffic through the CLAT as the
host has more specifics, regardless of whether it is a host or the border CPE.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Nov 2018 15:34:01 +0700

For more information, the proposal was originally made here
<https://mailarchive.ietf.org/arch/msg/ipv6/ek3DOKesF_RyebwAie1YLDzKkv8>.
I'm not sure whether it's worth doing this, because:

   1. It complicates the implementation.
   2. It can substantially increase the size of the option (looks like it's
   at least 8 bytes per prefix), and the space available in an RA packets is
   quite limited.
   3. RFC 3123 is experimental (since 2001), whereas this draft is intended
   to be a standards track document.
   4. AIUI, the option is not useful on an IPv6-only network. It is only
   useful in the case where the host has an IPv4 address. In that case the
   network might as well provide IPv4.

Mark, do you have a use case for #4? It's clear that this would be useful
DNS64 translator that provides service to other hosts, but for the case
where the host is just doing DNS64 synthesis for itself, the use case seems
less clear.

On Tue, Nov 6, 2018 at 3:20 PM Mark Andrews <[email-masked]> wrote:

> I want a option to be able to configure name servers that do DNS64 inside
> a network with local dual stack.  This requires knowing what IPv4 addresses
> are not to be translated and which IPv6 addresses to ignore and perform
> DNS64 synthesis on the IPv4 address.  Both of these ACLs can be provided at
> a single name with a APL record.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 6 Nov 2018 19:43:41 +1100

> On 6 Nov 2018, at 7:34 pm, Lorenzo Colitti <[email-masked]> wrote:
> 
> For more information, the proposal was originally made here. I'm not sure whether it's worth doing this, because:
> 	• It complicates the implementation.
> 	• It can substantially increase the size of the option (looks like it's at least 8 bytes per prefix), and the space available in an RA packets is quite limited.
> 	• RFC 3123 is experimental (since 2001), whereas this draft is intended to be a standards track document.
> 	• AIUI, the option is not useful on an IPv6-only network. It is only useful in the case where the host has an IPv4 address. In that case the network might as well provide IPv4.

For local ipv6-only only the filtering of IPv6 is useful and possibly could be skipped to just use well known values to skip.

> Mark, do you have a use case for #4? It's clear that this would be useful DNS64 translator that provides service to other hosts, but for the case where the host is just doing DNS64 synthesis for itself, the use case seems less clear.

The host still needs to know what addresses to not translate at the application level so long as we are locally dual stack.  You don’t want to send local traffic for IPv4 only local devices through the NAT64.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Nov 2018 15:52:44 +0700

On Tue, Nov 6, 2018 at 3:43 PM Mark Andrews <[email-masked]> wrote:

> >       • AIUI, the option is not useful on an IPv6-only network. It is
> only useful in the case where the host has an IPv4 address. In that case
> the network might as well provide IPv4.
>
> For local ipv6-only only the filtering of IPv6 is useful and possibly
> could be skipped to just use well known values to skip.
>

What would be the purpose of such filters? A host that supports 464xlat is
just going to get the A record and send the packet to the NAT64 anyway, no?

> The host still needs to know what addresses to not translate at the
> application level so long as we are locally dual stack.  You don’t want to
> send local traffic for IPv4 only local devices through the NAT64.
>

Can you provide an example scenario here? A host on a home network that has
IPv4 as well as NAT64? Why would you deploy this as opposed to doing, say,
464xlat on the home gateway?

---

From: Mark Andrews <[email-masked]>
Date: Tue, 6 Nov 2018 19:55:20 +1100

> On 6 Nov 2018, at 7:43 pm, Mark Andrews <[email-masked]> wrote:
> 
> 
> 

The code point is assigned.  There is a very clear description of the record structure.

Experimental is a red herring here.  All servers can handle this record either an a known type because they have implemented APL or a unknown type as there is nothing in the packet format that prevents unknown type processing being used for this record.

The following are identical records.

	example. IN TYPE42 \# 1 00010000
	example. IN APL 0:0.0.0.0/0
	example. IN APL \# 1 00010000
	example. IN TYPE42 0:0.0.0.0/0

---

From: Mark Andrews <[email-masked]>
Date: Tue, 6 Nov 2018 20:03:13 +1100

> On 6 Nov 2018, at 7:52 pm, Lorenzo Colitti <[email-masked]> wrote:
> 
> What would be the purpose of such filters? A host that supports 464xlat is just going to get the A record and send the packet to the NAT64 anyway, no?
> 
> Can you provide an example scenario here? A host on a home network that has IPv4 as well as NAT64? Why would you deploy this as opposed to doing, say, 464xlat on the home gateway?

Because you want to move the traffic to IPv6 as early as possible to remove load from the router.
Because your router doesn’t have a CLAT.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 06 Nov 2018 23:52:19 +0700

Hi Mark,

Trying to understand your scenario ...

Let's say I've an enterprise network which is dual-stack.

In the same network (before the NAT64), you have servers, with use private IPv4 addresses and they have A records for their names.

The ideal solution, of course, is to have those servers with also AAAA records and be dual-stacked.

Is this your scenario?

So, if we have a way to inform the any "entity" doing the DNS64 function to not synthetize the AAAA RRs, you will reach those host using IPv4 in the private network.

I'm assuming that the "entity" doing the DNS64 is the stack, happy eyeballs, or similar, in the local host that want to reach the IPv4-only server. Because the problem doesn't exist if the synthesis is done in a DNS64 server, as you can then use the mapping-out function. I described it in section 4.1.6.  Mapping-out IPv4 addresses (discussing there the DNSSEC implications), of https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment.

In the case you describe, this will only happen if the first-hop router from the LAN where a host tries to reach one of those servers, doesn't have a CLAT, otherwise even in the case it gets only an A record, will translate it (NAT46).

BUT, if this network is dual-stack, why I need a NAT64/DNS64 at all?

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Mark Andrews <[email-masked]>
Fecha: martes, 6 de noviembre de 2018, 16:03
Para: Lorenzo Colitti <[email-masked]>
CC: 6man <[email-masked]>
Asunto: Re: DNS64 pref option.

    

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 7 Nov 2018 07:39:08 +1100

Dual stack network doesn’t mean all devices connected to it are dual stack.   There is still a lot of IPv4 only garbage being sold with some classes of device without a IPv6 capable alternative. 

Deliberately creating bad AAAA records is a bad thing.  Sending traffic to those addresses is a bad thing. 

If you have a internally routed local dual stack network you don’t even have the IPv4 default pointing at a local CLAT to help.

As for Ipv4only.arpa APL records should also be published there.   
-- 
Mark Andrews

> On 7 Nov 2018, at 03:52, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 
> Hi Mark,
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 7 Nov 2018 11:11:45 +0700

I still don't see a use case here.

By definition, this is only useful if the host has both an IPv4 and IPv6
addresses. If the host has an IPv4 address, then it must have global
reachability (either through NAT44 or 464xlat or whatever else) because
otherwise IPv4 apps will be broken. If it does have global reachability,
then there is no use point in the host doing any DNS64 synthesis. IPv4
traffic will use IPv4 (which may end up going through 464xlat and NAT64),
and native IPv6 traffic will use IPv6.

What am I missing?

On Wed, Nov 7, 2018 at 3:39 AM Mark Andrews <[email-masked]> wrote:

> Dual stack network doesn’t mean all devices connected to it are dual
> stack.   There is still a lot of IPv4 only garbage being sold with some
> classes of device without a IPv6 capable alternative.
>
> If you have a internally routed local dual stack network you don’t even
> have the IPv4 default pointing at a local CLAT to help.
>
> > In the same network (before the NAT64), you have servers, with use
> private IPv4 addresses and they have A records for their names.
> >
> > So, if we have a way to inform the any "entity" doing the DNS64 function
> to not synthetize the AAAA RRs, you will reach those host using IPv4 in the
> private network.
> >
> > I'm assuming that the "entity" doing the DNS64 is the stack, happy
> eyeballs, or similar, in the local host that want to reach the IPv4-only
> server. Because the problem doesn't exist if the synthesis is done in a
> DNS64 server, as you can then use the mapping-out function. I described it
> in section 4.1.6.  Mapping-out IPv4 addresses (discussing there the DNSSEC
> implications), of
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment.
> >
> > In the case you describe, this will only happen if the first-hop router
> from the LAN where a host tries to reach one of those servers, doesn't have
> a CLAT, otherwise even in the case it gets only an A record, will translate
> it (NAT46).
> >
> >> What would be the purpose of such filters? A host that supports 464xlat
> is just going to get the A record and send the packet to the NAT64 anyway,
> no?
> >>
> >>> Mark, do you have a use case for #4? It's clear that this would be
> useful DNS64 translator that provides service to other hosts, but for the
> case where the host is just doing DNS64 synthesis for itself, the use case
> seems less clear.
> >>
> >> Can you provide an example scenario here? A host on a home network that
> has IPv4 as well as NAT64? Why would you deploy this as opposed to doing,
> say, 464xlat on the home gateway?
> >
> > This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
> >
> >
> >
>
>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 7 Nov 2018 15:43:32 +1100

> On 7 Nov 2018, at 3:11 pm, Lorenzo Colitti <[email-masked]> wrote:
> 
> By definition, this is only useful if the host has both an IPv4 and IPv6 addresses. If the host has an IPv4 address, then it must have global reachability (either through NAT44 or 464xlat or whatever else) because otherwise IPv4 apps will be broken. If it does have global reachability, then there is no use point in the host doing any DNS64 synthesis. IPv4 traffic will use IPv4 (which may end up going through 464xlat and NAT64), and native IPv6 traffic will use IPv6.
> 
> What am I missing?

Your “must” is not “must”.  Why must there be a NAT44 or CLAT?

Even if you have a CLAT (or IPv4 default route sink) and DNS64 then IPv4 traffic will be local or indication that there are applications / nodes / whatever that you need to upgrade.

A DNS64 aware getaddrinfo can apply DNS64 rules to both names and address literals but that only makes sense if you know what to exclude from the translation.  getaddrinfo already handles address literals.

Mark

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 7 Nov 2018 11:53:19 +0700

> Your “must” is not “must”.  Why must there be a NAT44 or CLAT?

Because IPv4-only applications will break if there is an IPv4 address that
does not have global connectivity. A deployment scenario in which IPv4-only
applications will break is not really deployable.

At this point I'm starting to conclude that there is really no actual
deployment scenario where this would be useful. If there is, then please
provide more details. Those details would need to include who might deploy
this, in what environment, using what devices, and so on. Without that,
it's very hard to come up with convincing motivation to add this to the
draft.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 07 Nov 2018 12:36:14 +0700

I’ve the same problem, I don’t “visualize” the scenario and will love to understand it.

May be some kind of “graphic” may help to understand it.

Regards,

Jordi

De: Lorenzo Colitti <[email-masked]>
Fecha: miércoles, 7 de noviembre de 2018, 11:53
Para: Mark Andrews <[email-masked]>
CC: Jordi Palet Martinez <[email-masked]>, 6man <[email-masked]>
Asunto: Re: DNS64 pref option.

Because IPv4-only applications will break if there is an IPv4 address that does not have global connectivity. A deployment scenario in which IPv4-only applications will break is not really deployable.

At this point I'm starting to conclude that there is really no actual deployment scenario where this would be useful. If there is, then please provide more details. Those details would need to include who might deploy this, in what environment, using what devices, and so on. Without that, it's very hard to come up with convincing motivation to add this to the draft.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Nov 2018 13:23:09 +0700

Lorenzo Colitti <lorenzo=[email-masked]> wrote:
    > otherwise IPv4 apps will be broken. If it does have global

I think we are considering cases where there is an IPv4 on the interface
(possibly IPv4 LL), but no IPv4 default route.   I think that it is much
better to consider the default route as the signal to do DNS64/NAT64.
(And yes, I would prefer all the DNS64 was all in the host)

The host is "dual-stack" in order to talk to the "crap" tha Andrew mentioned,
not because it's a good idea.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 7 Nov 2018 14:00:17 +0700

On Wed, Nov 7, 2018 at 1:23 PM Michael Richardson <[email-masked]>
wrote:

> (possibly IPv4 LL), but no IPv4 default route.

I don't see how that is deployable today though. IPv4-only apps exist and
will exist for quite a while yet. No?

The host is "dual-stack" in order to talk to the "crap" tha Andrew
> mentioned,

The applications talking to that "crap" (whatever it is) may well be
IPv4-only though. If they are, the device might not be able to talk to said
"crap" anyway, even if it has IPv4 link-local.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Nov 2018 18:29:02 +0700

Lorenzo Colitti <[email-masked]> wrote:
    >     > By definition, this is only useful if the host has both an IPv4 and
    >     > IPv6
    >     > addresses. If the host has an IPv4 address, then it must have global
    >     > reachability (either through NAT44 or 464xlat or whatever else)
    >     >  because
    >     > otherwise IPv4 apps will be broken. If it does have global

    mcr> I think we are considering cases where there is an IPv4 on the interface
    mcr> (possibly IPv4 LL), but no IPv4 default route.

    > I don't see how that is deployable today though. IPv4-only apps exist and will
    > exist for quite a while yet. No?

I'm not sure I understand.
IPv4 is deployed today.
I can do "telnet my-old-lexmark-printer", given that the name is in
/etc/hosts or internal DNS, or maybe it's new enough that it speaks mDNS.

Assume that IPv4 DHCP goes away along with IPv4 default route.
I can still reach the printer on link-local (assuming I renumber the printer
to static IPv4, given that DHCPv4 went away)

    mcr> The host is "dual-stack" in order to talk to the "crap" tha Andrew
    mcr> mentioned,
    mcr> not because it's a good idea.

    > The applications talking to that "crap" (whatever it is) may well be IPv4-only
    > though. If they are, the device might not be able to talk to said "crap"
    > anyway, even if it has IPv4 link-local.

Printers are a good example.
Some are old v4, some are new v6-happy.
CUPS is dual-stack.

Letting parts of the network talk to local devices which are not v6 capable
means we can move to v6-only at the Enterprise level sooner.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 7 Nov 2018 18:48:45 +0700

> Assume that IPv4 DHCP goes away along with IPv4 default route.

Right. That's the part that is not deployable today, because of IPv4-only
apps. Even iOS still has lots of problems with things like VPN apps, and I
hear that iOS 12 has a 464xlat implementation.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 07 Nov 2018 19:39:47 +0700

My understanding is that iOS 12 got 464XLAT only for the tethering (I guess only if by means of the cellular network), and not sure if shared only via wifi or also Bluetooth, usb, etc.

For built-in usage (example, browser with literals), happy eyeballs v2 resolves it via bump-in-the-host and built-in synthesis so the NAT64 can be used.

Regards,

Jordi

De: ipv6 <[email-masked]> en nombre de Lorenzo Colitti <lorenzo=[email-masked]>
Fecha: miércoles, 7 de noviembre de 2018, 18:49
Para: Michael Richardson <[email-masked]>
CC: 6man <[email-masked]>
Asunto: Re: DNS64 pref option.

Right. That's the part that is not deployable today, because of IPv4-only apps. Even iOS still has lots of problems with things like VPN apps, and I hear that iOS 12 has a 464xlat implementation.

-------------------------------------------------------------------- IETF IPv6 working group mailing list [email-masked] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Nov 2018 20:15:28 +0700

Lorenzo Colitti <[email-masked]> wrote:
    >     > I don't see how that is deployable today though. IPv4-only apps exist
    > and will
    >     > exist for quite a while yet. No?

    mcr> I'm not sure I understand.
    mcr> IPv4 is deployed today.
    mcr> I can do "telnet my-old-lexmark-printer", given that the name is in
    mcr> /etc/hosts or internal DNS, or maybe it's new enough that it speaks mDNS.

    mcr> Assume that IPv4 DHCP goes away along with IPv4 default route.

    > Right. That's the part that is not deployable today, because of IPv4-only apps.
    > Even iOS still has lots of problems with things like VPN apps, and I hear that
    > iOS 12 has a 464xlat implementation.

I don't understand your statement.
Which part is not deployable?
IPv6 NAT64/DNS64?
IPv6-only networks?

It can't be the IPv4-only printer, because that's already deployed.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 8 Nov 2018 11:03:43 +1100

> On 8 Nov 2018, at 12:15 am, Michael Richardson <[email-masked]> wrote:
> 

Lorenzo thinks that you can’t deploy a dual-stack local network without also deploying 464XLAT in the CPE router.  That is true to a certain extent today because the exclusion information isn’t published so that the node can't actually make the decision about which IPv4 traffic to send out the interface and which to send through the local CLAT.

He is then using that to make the argument that we shouldn’t publish a way to get the information because *today* you don’t have it and you use a kludge in the router to paper over the fact.

I’d like to get to the state where the node can decide which traffic needs to translated and what doesn’t.  We could even get to the state where a local CLAT is not needed if IPv4 literals are sent through getaddrinfo() and correctly mapped to IPv6 addresses.  IPv4 literals should already be being sent through getaddrinfo() so the host can use mapped IPv4 addresses.  This is just a different mapping.

getaddrinfo() is the architecturally correct place to do DNS64 mappings for both A records and IPv4 literals but you can’t get to do that if you don’t have the exclusion mapping published.  It is quite possible to publish similar information at ipv4only.arpa and I would expect enterprises and homes to do.  We would need to publish a document describing this.  We already have a document in the works saying that it is ok to publish your own ipv4only.arpa thanks to Stuart Cheshire.  It would only take a additional section in that document to say also publish the exclusion mapping using APL at ipv4only.arpa as well as the mapped AAAA record. I would not expect ISPs to do as they do not know what addresses are in use behind the IPv6-only access link.

Mark

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Nov 2018 13:32:27 +0700

Thank you for the interpretation, which I snipped out.

Mark Andrews <[email-masked]> wrote:
    > I’d like to get to the state where the node can decide which traffic
    > needs to translated and what doesn’t.  We could even get to the state
    > where a local CLAT is not needed if IPv4 literals are sent through
    > getaddrinfo() and correctly mapped to IPv6 addresses.  IPv4 literals
    > should already be being sent through getaddrinfo() so the host can use
    > mapped IPv4 addresses.  This is just a different mapping.

I concur with you.

---

From: Jen Linkova <[email-masked]>
Date: Mon, 12 Nov 2018 11:54:37 +1100

Hi Mark,

> getaddrinfo() is the architecturally correct place to do DNS64 mappings for both A records and IPv4 literals but you can’t get to do that if you don’t have the exclusion mapping published.  It is q…

I'm not convinced that such information needs to be carried in pref64
RA option as it would complicate the option format and implementations
while all use cases we've been talking so far do not exist (yet).

How about we keep those two things (pref64 and APL) separate and use
another RA option for the APL?

--
SY, Jen Linkova aka Furry

---

From: Ole Troan <[email-masked]>
Date: Mon, 12 Nov 2018 09:53:57 +0100

> getaddrinfo() is the architecturally correct place to do DNS64 mappings for both A records and IPv4 literals but you can’t get to do that if you don’t have the exclusion mapping published.  It is q…

So we are essentially talking about passing IPv4 routing information in IPv6 RAs.

I am not very keen on doing that.
Nor am I too happy about this making 6man into behave...
Are there no existing options that can be used?
RFC7598?

The actual NAT64 use cases here are not within 6man scope.

Best regards,
Ole