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

[Lencse Gábor <[e-mail]>]

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

>
>
> 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 <[e-mail]> en nombre de Lencse Gábor <[e-mail]>
>
> Fecha: jueves, 28 de junio de 2018, 21:48
>
> Para: <[e-mail]>
>
> Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments
>
>
>
>      Dear Fred and Jordi,
>
>      
>
>      As an academic researcher, I think this draft makes sense and I support
>
>      its adoption.
>
>      
>
>      I have one minor comment regarding the figure below:
>
>      
>
>      >> 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|     +------+
>
>      >                            +------+
>
>      
>
>      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
>
>      
>
>      
>
>      _______________________________________________
>
>      v6ops mailing list
>
>      [e-mail]
>
>      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.
>
>
>