IETF Logo Mail Archive

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

Lencse Gábor <lencse@hit.bme.hu> Thu, 28 June 2018 19:47 UTC

Return-Path: <lencse@hit.bme.hu>
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 DA4F4131068 for <v6ops@ietfa.amsl.com>; Thu, 28 Jun 2018 12:47:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 TfQSV-ZOPChf for <v6ops@ietfa.amsl.com>; Thu, 28 Jun 2018 12:47:09 -0700 (PDT)
Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B5A8131058 for <v6ops@ietf.org>; Thu, 28 Jun 2018 12:47:09 -0700 (PDT)
Received: from [192.168.1.116] (host-79-121-42-98.kabelnet.hu [79.121.42.98]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id w5SJl0fg074911 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <v6ops@ietf.org>; Thu, 28 Jun 2018 21:47:06 +0200 (CEST) (envelope-from lencse@hit.bme.hu)
X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-42-98.kabelnet.hu [79.121.42.98] claimed to be [192.168.1.116]
To: v6ops@ietf.org
References: <663F489C-7F63-4B0C-A5E6-F7EE4634E62B@gmail.com>
From: Lencse Gábor <lencse@hit.bme.hu>
Message-ID: <6ac32868-e0eb-00b7-2c3e-29c33c168323@hit.bme.hu>
Date: Thu, 28 Jun 2018 21:46:57 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <663F489C-7F63-4B0C-A5E6-F7EE4634E62B@gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.100.0 at frogstar.hit.bme.hu
X-Virus-Status: Clean
Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.42.98; helo=[192.168.1.116]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10;
X-DCC--Metrics: frogstar.hit.bme.hu; whitelist
X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/D3jTzV-Rh_3l-8MINgszF5gEHrU>
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 19:47:12 -0000

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

v2.23.0 | Report a Bug | By Email