IETF Logo Mail Archive

Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-deployment-00.txt

Erik Kline <ek@google.com> Tue, 10 October 2017 10:04 UTC

Return-Path: <ek@google.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 D262E134C2B for <v6ops@ietfa.amsl.com>; Tue, 10 Oct 2017 03:04:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=google.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 8Nf2oMOwqf66 for <v6ops@ietfa.amsl.com>; Tue, 10 Oct 2017 03:04:34 -0700 (PDT)
Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 16F46134BF1 for <v6ops@ietf.org>; Tue, 10 Oct 2017 03:04:34 -0700 (PDT)
Received: by mail-qt0-x22d.google.com with SMTP id n61so21533384qte.10 for <v6ops@ietf.org>; Tue, 10 Oct 2017 03:04:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5DzFZQwLjidREJJcvuIwTWfsYPyjvBpDZNI+d/K85Hk=; b=ZyrXXtSiv+uORPikkiaLqwMs//Ilghdc0m9wLOfofM54cGNucgqXxv81XabUi9jr6k LwbIbJIHkovlFYMSq9v/2jouvtgDc2cHaHPLfofR++4JtCLEKeXojHYvUbIwKO3aED1V AnGXSXRFZBafr0L/WYs0ARvxMJrw1JbIfKtedYj6qpP5WdQuW66VZh2fuky6cudXmX5h DC+bSfaJeCJZOA9x4S4GLGv/U+nFR6wTLriIDpNf6AO05vxATu3GJKXyLlCYGsr27q4T K4MKI6GZVmGKp+jZwDlHXCLC1qFNEFxuy/oAlEjWcSwYYFEluHHCuQ4YC94D6nKs1JI8 bd4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5DzFZQwLjidREJJcvuIwTWfsYPyjvBpDZNI+d/K85Hk=; b=PHW0VPuLRqBmJ3yCSxaRNGD1n960jro6cnN1fc2f96wWjvDqJD9xGub2oztahNpobC wijycOc6MVdz0zRonh1ByZEBgYb9IAKdrS91BlEqM05aJQBPxYP+0k1hZtKGUSK3yl+p 1jul/pfOYY1M250z9DVOXKjPzodIV1k2ZB2h9JhW/iwCWncrVZGBq9no6UWNPYz/3GGw 8/eIt0ixEwVhBlfDgSmRPSEX4Yy3JBXodzAtprqe6XpRIPIOLNQV9Zgby4++5AO8ZuD7 yndUuDfWd9oh9678sDUBIhAkZ0wDGzxX/r1i3YO6l6PlJRWP9pqLGPODPTfSPLFIssjS e9TQ==
X-Gm-Message-State: AMCzsaWQ8i9OsZRwocPphCoas41jQscEfZ7Dt7HkST8V4JK7NgeqmUH4 H6S6kpSFrStyIWBH09Di8be9efmnDlqw63RmieK+Mg==
X-Google-Smtp-Source: AOwi7QAimrycUr+xKcPZdcoJ6DiGLc9KiZYdCQQ7rg35DfMVQ+np6z1FsIKrR2iyX+uvhdGy7UkS8JammlxigDU8jV0=
X-Received: by 10.129.228.4 with SMTP id r4mr1720712ywl.13.1507629872853; Tue, 10 Oct 2017 03:04:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.187.5 with HTTP; Tue, 10 Oct 2017 03:04:12 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.20.1710101137120.31961@uplift.swm.pp.se>
References: <150755581666.18336.7914755965262691836.idtracker@ietfa.amsl.com> <CB970DA1-7E14-4E38-8FE1-535108518819@consulintel.es> <CAD6AjGQJXFOEysWbDRM3JZwy2JKquxzpTTDy5_XbOm7-Db7xjg@mail.gmail.com> <alpine.DEB.2.20.1710091711380.31961@uplift.swm.pp.se> <D4D1D13A-6B68-4FF8-BF11-922813CC7F6E@consulintel.es> <alpine.DEB.2.20.1710101137120.31961@uplift.swm.pp.se>
From: Erik Kline <ek@google.com>
Date: Tue, 10 Oct 2017 19:04:12 +0900
Message-ID: <CAAedzxrZ-3xOH8AxGUR0aXfguC-ENrHngEUj_-OGS5zMQMEcaQ@mail.gmail.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, IPv6 Ops WG <v6ops@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="089e0821f2b80ef752055b2e6f99"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/klnGW9CQz-iDl9OI9hAxAq9_oGY>
Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-deployment-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 10 Oct 2017 10:04:39 -0000

On 10 October 2017 at 18:50, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> On Tue, 10 Oct 2017, JORDI PALET MARTINEZ wrote:
>
>> Hi Mikael,
>>
>> So, in your opinion, if I understand it correctly:
>> 1) DNSSEC must not be ignored
>> 2) DNS64 should be supported
>
>
> Correct. Don't know exactly how to do that, but that's what I'd like to see.
>
>> Could you agree in a document that describes different deployment models
>> supporting or not 1, 2, above?
>
>
> I'm just speculating/brainstorming here... but let me write some text and
> see what people think:
>
> 1. A DNS64 resolver should do DNSSEC validation before synthesis.
>
> 2. A device behind DNS64 that intends to do DNSSEC validataion should
> identify the NAT64 prefix via the standard means, and then it should (if
> DNSSEC validation fails on AAAA question) do DNSSEC validation of A record
> and perform its own DNS64 function (if the AAAA answer that failed DNSSEC
> validation fell within the discovered NAT64 prefix).
>
> I wasn't there during the DNS64 work, I don't know if these things were
> discussed and rejected for good reasons but... Have at me.

https://tools.ietf.org/html/rfc6147#section-6.2

v2.23.0 | Report a Bug | By Email