Subject: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments

From: Fred Baker <[email-masked]>
Date: Wed, 27 Jun 2018 12:04:34 -0500

Chair comment: I am interested in making this draft a working group draft. I think there is merit in it to do so. However, following our usual process, I need agreement from the working group. Consider this a solicitation for that. To do so, I'm looking for comments, supportive or otherwise, especially from operators. To respond to Barbara's question that she raised with ipv4aas, making it a working group document doesn't mean it's done, it means it's a work item as opposed to a suggestion to the working group.

The rest of this is sans hats.

Thanks for your new draft. Let me say that I am increasingly hearing about ISPs (cellular and broadband) that, in the words of one, "just don't want to allocate IPv4 addresses anymore", and are taking important steps toward turning IPv4 off within their networks in favor of IPv4 as a service. As you know, this falls into a couple of categories - those that are willing to offer a client-only IPv4-over-IPv6 or IPv4-cum-IPv6 service, and those that need to be able to somehow still put an IPv4 address into an A record (such as a company like Lumix that uses Dynamic DNS Update and firewall hole-punching to allow a residential user to access their surveillance system from an Android/iPhone app) and use it to send a message to the IPv4 server. So IMHO, this is an important draft, and it would be useful to get operator comment on it.

I'm reviewing the draft. I'll bring up nits inline, and I may have some other thoughts as well.

> Abstract
> 
>    This document describes how NAT64 and 464XLAT can be deployed in an
>    IPv6 operator (cellular and broadband) or enterprise network and the

I suspect that this would read better as "IPv6 network, whether cellular ISP, broadband ISP, or enterprise".

> 1.  Introduction

>    To avoid changes in both, the IPv6-only hosts and the IPv4-only
>    server, NAT64 requires also the use of a DNS64 ([RFC6147]), in charge
>    for the synthesis of AAAA records from the A records.

I would disagree that NAT64 "requires" DNS64. NAT64 requires that the destination IPv6 address contain an embedded IPv4 address. The source of that IPv4-embedded IPv6 address is up to the system that sent the packet. A CLAT (stateless translation as in RFC 7915) uses address synthesis with a PLAT translation prefix. MAP-T adds NAPT44 functionality to that with respect to the outbound IPv4 source address. A random IPv6 host accessing an IPv4-only peer might use DNS64, and the AAAA records might simply exist in DNS containing an IPv4-embedded IPv6 address. But the NAT64 function doesn't use, nor does it require, DNS64.

BTW, SIIT-DC makes rather a point that RFC 6146 is a per-session (effectively NAPT) translator, and provides translation strictly at the IP layer. I suspect that is also a valid configuration, one that needs to be supported. In the 464XLAT case, I think it falls out, but I'll have to think about MAP-T.

> 3.  NAT64 Deployment Scenarios

>    Consequently, the perspective in this document is to broader those

"broaden"

> 3.1.2.  Service Provider offering 464XLAT, with DNS64

Pictorial image of what I'm picturing:

                          +----+                +----+
                          |DNS |     +-----+    |DNS |
                          |IPv6|     |DNS64|    |IPv4|
                          +--+-+     +--+--+    +--+-+
  +------+ v6 +------+       |          |          |
  |      +----+      |    ,--+--.       |       ,--+--.
  |Dual  |    | IPv6 |   /       \    ,-+-.    /       \
  |Stack |  +-+Router+--(  IPv6   )--( PLAT)--(  IPv4   )
  |Device|v4|C|      |   \Network/`.  `---'    \Network/
  |      +--+L|      |    `--+--'   `.         /`-----'
  +------+  |A|      |       |        `+------+
            |T|      |    +--+---+     | Peer |
            +-+------+    | IPv6 |     |Device|
                          |Device|     +------+
                          +------+

The dual stack device obviously has an IPv4 and an IPv6 address, and the IPv4 side of it speaks through the CLAT. The IPv6 device has no IPv4 address. The peer device is the thing the "dual stack" device connects to, and might itself be dual stack or IPv4-only. In both cases, however, IPv4 access to the peer device will go through the PLAT.

When the IPv6 device wants to talk with the peer device, it will need a AAAA record. In the dual stack case, that will contain a "usual" IPv6 address, and connectivity will be IPv6 end to end; in the IPv4-only case, it will need its IPv4 address embedded into the PLAT's translation prefix, which is or is functionally equivalent to DNS64.

When the dual stack device wants to talk with the Peer Device, its IPv4 side will need an A record and the CLAT will do the address synthesis. Hence, no need for DNS64, and no requirement for it if it exists. The IPv6 side will need a AAAA record. If there is a native IPv6 address, that's fine, it will use that, and the system might be best served if the IPv6 connectivity is used. If there is a DNS64 AAAA record, the IPv4 side will use an A record and the CLAT and PLAT, and the IPv6 side will use the PLAT and the DNS64 address.

> 3.1.3.  Service Provider offering 464XLAT, without DNS64

The difference from the preceding section will be connectivity between an IPv6-only device and an IPv4-only peer. In the previous section, the IPv6 device will be unable to communicate with an IPv4-only peer, and the dual stack device will use its IPv4 side, the CLAT, and the PLAT.

>    The major advantage of this scenario, using 464XLAT without DNS64, is
>    that the service provider ensures that DNSSEC is never broken.

Yes, but at the cost of IPv6-IPv4 connectivity.

> 3.2.  Known to Work Under Special Conditions
> 
>    The scenarios in this category are known not to work unless

"known to not work"

I'll probably have more comments later, but I'm sending this much now.

---

From: Alejandro D'Egidio <[email-masked]>
Date: Wed, 27 Jun 2018 15:43:33 -0300 (ART)

Jordi, Fred,
  As a network operator I think this is a great work. It give to us the possibility to have an IPv6 only access network where the need of IPv4 connectivity can be solved thanks to CLAT within the CPE, obviously we need also a NAT64 as PLAT.

  Thanks for this work.

Regards,

ALEJANDRO D'EGIDIO 
Jefe de Ingeniería de Backbone 
F: +54 11 3977 1025  | M: +54 911 5794 1589 
Lavardén 157. Piso 3. CABA (C1437FBC)

----- Mensaje original -----
De: "Fred Baker" <[email-masked]>
Para: "Jordi Palet Martínez" <[email-masked]>, "[email-masked] list" <[email-masked]>
Enviados: Miércoles, 27 de Junio 2018 14:04:34
Asunto: draft-palet-v6ops-nat64-deployment-02 comments

"broaden"

                          +----+                +----+
                          |DNS |     +-----+    |DNS |
                          |IPv6|     |DNS64|    |IPv4|
                          +--+-+     +--+--+    +--+-+

"known to not work"

---

From: Alejandro D'Egidio <[email-masked]>
Date: Wed, 27 Jun 2018 15:52:53 -0300 (ART)

Jordi, Fred,

  Thanks for this work.

Regards,

ALEJANDRO D'EGIDIO 

----- Mensaje original -----
De: "Fred Baker" <[email-masked]>
Para: "Jordi Palet Martínez" <[email-masked]>, "[email-masked] list" <[email-masked]>
Enviados: Miércoles, 27 de Junio 2018 14:04:34
Asunto: draft-palet-v6ops-nat64-deployment-02 comments

"broaden"

                          +----+                +----+
                          |DNS |     +-----+    |DNS |
                          |IPv6|     |DNS64|    |IPv4|
                          +--+-+     +--+--+    +--+-+

"known to not work"

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 27 Jun 2018 23:08:36 +0200

Hi Fred,

Thanks a lot !

Comments below in-line.

Regards,

Jordi

-----Mensaje original-----

De: v6ops <[email-masked]> en nombre de Fred Baker <[email-masked]>

Fecha: miércoles, 27 de junio de 2018, 19:05

Para: Jordi Palet Martínez <[email-masked]>, "[email-masked] list" <[email-masked]>

Asunto: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments

-> Agree and hopefully we can get a lot of contributions ...

-> Perfect, thanks a lot. I'm already doing edits in my draft v03, so I don't miss any bit.

-> Agree, I took it from an equivalent text in the abstract of DNS64, but it makes sense to put it in reverse:

"DNS64, is in charge of the synthesis of AAAA records from the A records, avoiding changes in both, the IPv6-only hosts and the IPv4-only server, so they can use a NAT64."

    "broaden"

                              +----+                +----+

                              |DNS |     +-----+    |DNS |

                              |IPv6|     |DNS64|    |IPv4|

                              +--+-+     +--+--+    +--+-+

                |T|      |    +--+---+     | Peer |

                              |Device|     +------+

                              +------+

-> Are you suggesting that I should make a more detailed description in every scenario, with more figures, etc. ? Or just in the 464XLAT case ?

-> Right, again, you feel I need to add text to explain that, so same as previous question, having some extra text only for the 464XLAT cases?

-> Yes, we are forcing one extra translation at the CE (which is the same as today happens with NAT44). I think if it is a choice of the operator to use DNS64 (and resolve a possible 1.7% - today - DNSSEC incidents), or make its life easier by forcing some extra translations that of course, will keep decreasing as more IPv6 deployment happens in services/content providers. If we take in consideration that 60% or so of the services more used (Youtube, Google, Facebook, etc.), area already IPv6 enabled, it means that in an ISP deploying IPv6, the number of "extra" translations at the CLAT will be really insignificant (and don't happen in the operator network, just in the CLAT) compared to the cost of breaking "some" DNSSEC.

    "known to not work"

    _______________________________________________

    v6ops mailing list

    [email-masked]

    https://www.ietf.org/mailman/listinfo/v6ops

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
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: Fred Baker <[email-masked]>
Date: Wed, 27 Jun 2018 20:55:59 -0500

> On Jun 27, 2018, at 4:08 PM, JORDI PALET MARTINEZ <[email-masked]> wrote:

>    Yes, but at the cost of IPv6-IPv4 connectivity.

I suppose in part I'm thinking out loud. But I do think it's important to not trivialize the lack of connectivity in that last case, which I think your current text does. Yes, DNSSEC doesn't work (doesn't validate a signature, and probably doesn't *have* a signature) with a DNS64 IPv4 embedded IPv6 Address. But it doesn't work without one either, because in the case nothing works - there is no connectivity. It's a judgement call, I suppose, but I think it's better to say it than let the installing ISP discover it and wonder what happened.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 28 Jun 2018 08:14:28 +0200

-> Understood. I will improve the text to avoid that trivialization. However, I don't agree it doesn't works. What happens is that in that case, the connection in that case is done using the IPv4 stack of both peers (so the dual-stack host behind the CLAT CE, only see an "A" record, so naturally use only that one).

---

From: Masanobu Kawashima <[email-masked]>
Date: Thu, 28 Jun 2018 11:57:02 +0000

Hi Jordi, 

I've read all of this draft. This is a great work and nice guideline. 

I'm not a network operator, but as one of CE router vendors, 
I'll recommend operators to read this document even if it is still individual draft. 
This document will help them for their decision, especially if they consider 
NAT64/464XLAT. 

Anyway, I support this document as a working group document. 
I may input some information when I get comments from them. 

Regards, 
Masanobu 

==================================== 
 NEC Platforms, Ltd.                 
 KAWASHIMA Masanobu                  
 [email-masked]            
 https://www.necplatforms.co.jp/en/  
==================================== 

> -----Original Message-----
> From: v6ops <[email-masked]> On Behalf Of Fred Baker
> Sent: Thursday, June 28, 2018 2:05 AM
> To: Jordi Palet Martínez <[email-masked]>; [email-masked] list <[email-masked]>
> Subject: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments
> 
> Chair comment: I am interested in making this draft a working group draft. I think there is merit in it to do so.
> However, following our usual process, I need agreement from the working group. Consider this a solicitation for that.
> To do so, I'm looking for comments, supportive or otherwise, especially from operators. To respond to Barbara's question
> that she raised with ipv4aas, making it a working group document doesn't mean it's done, it means it's a work item
> as opposed to a suggestion to the working group.
> 
> Thanks for your new draft. Let me say that I am increasingly hearing about ISPs (cellular and broadband) that, in
> the words of one, "just don't want to allocate IPv4 addresses anymore", and are taking important steps toward turning
> IPv4 off within their networks in favor of IPv4 as a service. As you know, this falls into a couple of categories
> - those that are willing to offer a client-only IPv4-over-IPv6 or IPv4-cum-IPv6 service, and those that need to be
> able to somehow still put an IPv4 address into an A record (such as a company like Lumix that uses Dynamic DNS Update
> and firewall hole-punching to allow a residential user to access their surveillance system from an Android/iPhone
> app) and use it to send a message to the IPv4 server. So IMHO, this is an important draft, and it would be useful
> to get operator comment on it.
> 
> I would disagree that NAT64 "requires" DNS64. NAT64 requires that the destination IPv6 address contain an embedded
> IPv4 address. The source of that IPv4-embedded IPv6 address is up to the system that sent the packet. A CLAT (stateless
> translation as in RFC 7915) uses address synthesis with a PLAT translation prefix. MAP-T adds NAPT44 functionality
> to that with respect to the outbound IPv4 source address. A random IPv6 host accessing an IPv4-only peer might use
> DNS64, and the AAAA records might simply exist in DNS containing an IPv4-embedded IPv6 address. But the NAT64 function
> doesn't use, nor does it require, DNS64.
> 
> BTW, SIIT-DC makes rather a point that RFC 6146 is a per-session (effectively NAPT) translator, and provides translation
> strictly at the IP layer. I suspect that is also a valid configuration, one that needs to be supported. In the 464XLAT
> case, I think it falls out, but I'll have to think about MAP-T.
> 
> The dual stack device obviously has an IPv4 and an IPv6 address, and the IPv4 side of it speaks through the CLAT.
> The IPv6 device has no IPv4 address. The peer device is the thing the "dual stack" device connects to, and might itself
> be dual stack or IPv4-only. In both cases, however, IPv4 access to the peer device will go through the PLAT.
> 
> When the IPv6 device wants to talk with the peer device, it will need a AAAA record. In the dual stack case, that
> will contain a "usual" IPv6 address, and connectivity will be IPv6 end to end; in the IPv4-only case, it will need
> its IPv4 address embedded into the PLAT's translation prefix, which is or is functionally equivalent to DNS64.
> 
> When the dual stack device wants to talk with the Peer Device, its IPv4 side will need an A record and the CLAT will
> do the address synthesis. Hence, no need for DNS64, and no requirement for it if it exists. The IPv6 side will need
> a AAAA record. If there is a native IPv6 address, that's fine, it will use that, and the system might be best served
> if the IPv6 connectivity is used. If there is a DNS64 AAAA record, the IPv4 side will use an A record and the CLAT
> and PLAT, and the IPv6 side will use the PLAT and the DNS64 address.
> 
> The difference from the preceding section will be connectivity between an IPv6-only device and an IPv4-only peer.
> In the previous section, the IPv6 device will be unable to communicate with an IPv4-only peer, and the dual stack
> device will use its IPv4 side, the CLAT, and the PLAT.
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 28 Jun 2018 14:16:13 +0200

Hi Masanobu,

Thanks for this.

It will be nice if you can circulate the link around NOGs, so we can get more inputs on it.

Regards,

Jordi

-----Mensaje original-----

De: v6ops <[email-masked]> en nombre de Masanobu Kawashima <[email-masked]>

Fecha: jueves, 28 de junio de 2018, 13:58

Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments

    Hi Jordi, 

    NAT64/464XLAT. 

    Regards, 

    Masanobu 

     NEC Platforms, Ltd.                 

     KAWASHIMA Masanobu                  

     [email-masked]            

    

    v6ops mailing list

    [email-masked]

---

From: Fred Baker <[email-masked]>
Date: Thu, 28 Jun 2018 07:23:56 -0500

> -> Understood. I will improve the text to avoid that trivialization. However, I don't agree it doesn't works. What happens is that in that case, the connection in that case is done using the IPv4 s…

For the dual stack host behind the CLAT, yes. For the IPv6-only host, there is either no connectivity to an IPv4-only host, or it goes through the PLAT and DNSSEC is broken. There remains no connectivity using the signed DNSSEC A record, because the IPv6-only host isn't using it.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 28 Jun 2018 14:30:50 +0200

Do you think it makes sense today for a smart OS or app provider, knowing that that app need to talk to IPv4-only hosts, to make that app or OS, IPv6-only?

If I'm on their feet, will only make the app or OS IPv6-only once I'm 100% sure that what the peer I need to speak, is also IPv6-ready.

And by the way, this will only make sense when that OS or app provider knows for sure that their customers will get also IPv6 from their ISPs.

Or I'm missing something?

So what I'm saying is that supporting IPv6-only hosts is not making sense for now, and even if that is supported, that the ISP offers DNS64, all will get broken if the user changes the DNS servers ...

Regards,

Jordi

-----Mensaje original-----

De: Fred Baker <[email-masked]>

Fecha: jueves, 28 de junio de 2018, 14:24

Para: JORDI PALET MARTINEZ <[email-masked]>

CC: "[email-masked] list" <[email-masked]>

---

From: Fred Baker <[email-masked]>
Date: Thu, 28 Jun 2018 07:40:13 -0500

> Do you think it makes sense today for a smart OS or app provider, knowing that that app need to talk to IPv4-only hosts, to make that app or OS, IPv6-only?

I'm not making a market statement. I'm looking at a technical scenario, which I laid out in email yesterday. It could be IPv6-only because the network didn't give it an IPv4 address, to pick one possible reason out of a cloud of possible ones. The point is, it *is*, and if the peer it wants to talk with doesn't have a AAAA record, whether native or DNS64, it can't.

So the failure of DNSSEC when DNS64 is used isn't the only issue. Connectivity is also an issue. That's my whole point.

---

From: Lencse Gábor <[email-masked]>
Date: Thu, 28 Jun 2018 21:46:57 +0200

Dear Fred and Jordi,

As an academic researcher, I think this draft makes sense and I support 
its adoption.

> Pictorial image of what I'm picturing:

Connecting the DNS64 server to the PLAT device suggests me as if DNS64 
were a kind of subfunction of PLAT. Of course it is not the case. They 
can be implemented by two independent devices: stateful NAT64 is usually 
implemented by a router and DNS64 is usually implemented by a DNS server.

I have been thinking about an alternative drawing like this:

                           +----+                +----+
                           |DNS |     +-----+    |DNS |
                           |IPv6|     |DNS64|    |IPv4|
                           +--+-+     +-----+    +--+-+
   +------+ v6 +------+       |      /       \      |
   |      +----+      |    ,--+--.  /         \  ,--+--.
   |Dual  |    | IPv6 |   /       \/   ,---.   \/       \
   |Stack |  +-+Router+--(  IPv6   )--( PLAT)--(  IPv4   )
   |Device|v4|C|      |   \Network/`.  `---'    \Network/
   |      +--+L|      |    `--+--'   `.         /`-----'
   +------+  |A|      |       |        `+------+
             |T|      |    +--+---+     | Peer |
             +-+------+    | IPv6 |     |Device|
                           |Device|     +------+
                           +------+

What do you think of it?

Best regards,

Gabor

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 28 Jun 2018 22:58:51 +0200

Thanks Gabor!

I think the location of the DNS64 is not relevant, unless I'm missing something ... In fact, the "easier and most common" scenario is that the DNS itself (Bind, etc.), is also running the DNS64 function.

We could have 10 different pictures for it, the point is to clarify impacts of having it vs not, so to provide a decision point to an operator/enterprise willing to deploy it.

Regards,

Jordi

-----Mensaje original-----

De: v6ops <[email-masked]> en nombre de Lencse Gábor <[email-masked]>

Fecha: jueves, 28 de junio de 2018, 21:48

Para: <[email-masked]>

    Dear Fred and Jordi,

    its adoption.

                               +----+                +----+

                               |DNS |     +-----+    |DNS |

                               |IPv6|     |DNS64|    |IPv4|

                               +--+-+     +-----+    +--+-+

                 |T|      |    +--+---+     | Peer |

                               |Device|     +------+

                               +------+

    What do you think of it?

    Best regards,

    Gabor

    v6ops mailing list

    [email-masked]

---

From: Lencse Gábor <[email-masked]>
Date: Fri, 29 Jun 2018 10:15:36 +0200

6/28/2018 10:58 PM keltezéssel, JORDI PALET MARTINEZ írta:
> Thanks Gabor!
>
>
>
> I think the location of the DNS64 is not relevant, unless I'm missing something ...

Yes, I agree. The location of DNS64 by itself is not my concern. What I 
would like to emphasize is that DNS64 does not belong to NAT64. The 
reason, why I am aware of this is my experience with DNS64 and NAT64 
benchmarking.

In all other research papers than ours, they measured the performance of 
a given NAT64 implementation together with a given DNS64 implementation, 
which is a significant flaw. We have pointed out that their performances 
should be measured independently. And our approach was followed by RFC 
8219, too.

> In fact, the "easier and most common" scenario is that the DNS itself (Bind, etc.), is also running the DNS64 function.

You mentioned BIND, which is natural, as BIND is still considered the de 
facto industry standard DNS server.

However, when talking about DNS64, BIND is the worst solution. According 
to our benchmarking results, ISP-s should choose either Unbound or 
PowerDNS as DNS64 server, but not BIND. Let me support my statement with 
measurement results:

	PowerDNS 	Unbound 	BIND
1-core DNS64 performance (queries per second) 	3077 	8708 	2425
16-core DNS64 performance (queries per second) 	26620 	17131 	6661

The measurements complied with RFC 8219. For the details, please refer to:

G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: 
Theory and Practice", /Computer Communications/ (Elsevier), vol. 127, 
no. 1, pp. 61-74, September 1, 2018, DOI: 10.1016/j.comcom.2018.05.005

I think it would be worth mentioning these results in the draft, as they 
give useful guidelines for the DNS64 server implementation selection.

Best regards,

Gábor