IETF Logo Mail Archive

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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Thu, 28 June 2018 20:59 UTC

Return-Path: <prvs=17172b6c16=jordi.palet@consulintel.es>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2B0130F39 for <v6ops@ietfa.amsl.com>; Thu, 28 Jun 2018 13:59:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApLoj9jvEdBL for <v6ops@ietfa.amsl.com>; Thu, 28 Jun 2018 13:58:58 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DAC41310D7 for <v6ops@ietf.org>; Thu, 28 Jun 2018 13:58:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1530219535; x=1530824335; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=BMFxgEod 11k+SVpeGndHipK5j0VlBJeF0gNBG/axy0Q=; b=Gly437EtJ/rbkulJyKC3xseC +RHreeZcnkTKiz1+ZopUICq4nxh2Yz94abuO/vkQJhXBEYDgjiivkuQ/zZLEh+A/ HO3gB7URby8rfnBgjgatk98XrhsNEL3CLox8CutF6kOG94Y6JhSYmE5MLLmou3SU h3YVm218jzuZADplsd8=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Thu, 28 Jun 2018 22:58:55 +0200
X-Spam-Processed: mail.consulintel.es, Thu, 28 Jun 2018 22:58:55 +0200
Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005800045.msg for <v6ops@ietf.org>; Thu, 28 Jun 2018 22:58:54 +0200
X-MDRemoteIP: 2001:470:1f09:495:b929:51b1:8b6b:229c
X-MDHelo: [10.10.10.130]
X-MDArrival-Date: Thu, 28 Jun 2018 22:58:54 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=17172b6c16=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.e.1.180613
Date: Thu, 28 Jun 2018 22:58:51 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: Lencse Gábor <lencse@hit.bme.hu>, v6ops@ietf.org
Message-ID: <427C7EE4-7B07-4094-9315-01E03A5120B3@consulintel.es>
Thread-Topic: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments
References: <663F489C-7F63-4B0C-A5E6-F7EE4634E62B@gmail.com> <6ac32868-e0eb-00b7-2c3e-29c33c168323@hit.bme.hu>
In-Reply-To: <6ac32868-e0eb-00b7-2c3e-29c33c168323@hit.bme.hu>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/7cFjtJSJXi2wMP__VzUf5JRKzzk>
Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2018 20:59:16 -0000

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 <v6ops-bounces@ietf.org> en nombre de Lencse Gábor <lencse@hit.bme.hu>

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

Para: <v6ops@ietf.org>

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

    v6ops@ietf.org

    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.

v2.23.0 | Report a Bug | By Email