IETF Logo Mail Archive

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

Fred Baker <fredbaker.ietf@gmail.com> Mon, 02 July 2018 19:18 UTC

Return-Path: <fredbaker.ietf@gmail.com>
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 E8D551312B1 for <v6ops@ietfa.amsl.com>; Mon, 2 Jul 2018 12:18:34 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 hZOISvoEBhCl for <v6ops@ietfa.amsl.com>; Mon, 2 Jul 2018 12:18:25 -0700 (PDT)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62E451312AC for <v6ops@ietf.org>; Mon, 2 Jul 2018 12:18:15 -0700 (PDT)
Received: by mail-oi0-x231.google.com with SMTP id m2-v6so10520243oim.12 for <v6ops@ietf.org>; Mon, 02 Jul 2018 12:18:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=tPUWsLvKTsOB0Q1+6mCr1y9eFJwOEyrbIMiPRJlv8sA=; b=BMyiFZ2oQGOXDsRTsOC1aFXWXAp2f9HUUgEhXSjyZms258pXiPcEQUDBMXj0XM0dGK no09efrLvbxykJI4yfk2GrJ7WwNaAcp0FaQgIdEw9rPWH0G7wWI452LvT5Wi2Lfjf/8W 5VGZbNbNHr2HwNGahjTL2wiAKwgCvkKvyYXYgTX/GasRCI/lxxic/6tLZyqxq/FzZBDV FdbOOPKaJPBkHnfVpO/ZzFsEHqco/ReAVNqenlrSjG379RDdQMAOVmDRh4flwUIB8ZP6 PNcUtzpZL8JaOMnJHa0l6p7qzqhPZ8g3aq8yxM7ZaszVlJ8B1Fpeae3F4D9fOMtufohA 4lfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=tPUWsLvKTsOB0Q1+6mCr1y9eFJwOEyrbIMiPRJlv8sA=; b=HY/XkZr+spktmmSO+XxgaqfDWCwLFxNr0RZugk8DfH9+yvGt17GQEQQhuuGVl0Qz5E vH3QscG6oXfH233gwN8Z8PcS+CQ3L0r2Hz50iK3e5TYYLZoNg4TaD81fL9UROiNtHmay 4i6J8Xi4R+BbcWu8+wboTkHDkPn3sH6z0mE1Uv0p+kEbguelyiyIdxNxCyyPxWWbWnHl cbb9fGBSV7hu2GCs7ljIrqm7dbN4TraDDBdm6OACBbhrD2sxwxghpOk+l1mn84oNH3Jh 23xDlqLcaFWO1JAbjrdQ1XYD44nQiaaHZ26lhYv/5t7HUJQiUhwriMRfIqOPupW2wH0/ yWyw==
X-Gm-Message-State: APt69E0hXwF2U3xfmQshR0iBeXiv95wqWF4OPefOl/I8H2Zdm0J+/QUw BxcY10HUViNBIVy5VAVhBCo=
X-Google-Smtp-Source: AAOMgpcZe6wuUyrK6bSVvYqZSv8FP7Q9xrOswJrPU0NDVL1hGh/W2wFjEdndKBqsvYURvoQXksVHlg==
X-Received: by 2002:aca:6206:: with SMTP id w6-v6mr4525352oib.201.1530559094785; Mon, 02 Jul 2018 12:18:14 -0700 (PDT)
Received: from ?IPv6:2600:8802:5600:1546::101b? ([2600:8802:5600:1546::101b]) by smtp.gmail.com with ESMTPSA id d8-v6sm9414487oif.39.2018.07.02.12.18.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Jul 2018 12:18:13 -0700 (PDT)
From: Fred Baker <fredbaker.ietf@gmail.com>
Message-Id: <B16C597F-A360-4341-8124-EB18935B834C@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_A8E95509-3352-4FC9-BB6C-7EDEE5B7AC74"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 02 Jul 2018 12:18:10 -0700
In-Reply-To: <6ac32868-e0eb-00b7-2c3e-29c33c168323@hit.bme.hu>
Cc: v6ops@ietf.org
To: Lencse Gábor <lencse@hit.bme.hu>
References: <663F489C-7F63-4B0C-A5E6-F7EE4634E62B@gmail.com> <6ac32868-e0eb-00b7-2c3e-29c33c168323@hit.bme.hu>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/JcJOa_hL1_ymPSECgklVP7G4xqg>
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: Mon, 02 Jul 2018 19:18:42 -0000

I think your sketch is fine. There is one issue: the DNS64 has to perform address synthesis in the sense RFC 6877 uses the term. Yes, it will connect to the IPv4 network to access DNS and retrieve A records, and the IPv6 network to respond to DNS requests. It could also access the IPv6 network to get the relevant IPv6 prefix. In a network with multiple such prefixes, that could also be "interesting". I note that NAT64 implementations frequently have associated DNS64 implementations - not required, but simplifies knowing the relevant prefix. I connected DNS64 to the PLAT on the assumption that the PLAT talks to both, but certainly the drawing could show those directly.

> On Jun 28, 2018, at 12:46 PM, Lencse Gábor <lencse@hit.bme.hu> wrote:
> 
> 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

v2.23.0 | Report a Bug | By Email