Re: [DNSOP] AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Sat, 07 July 2018 12:05 UTC

Return-Path: <prvs=1726381e16=jordi.palet@consulintel.es>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8484A130DBE for <dnsop@ietfa.amsl.com>; Sat, 7 Jul 2018 05:05:11 -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] 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 wOiEDqEn9EOi for <dnsop@ietfa.amsl.com>; Sat, 7 Jul 2018 05:05:09 -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 3DD3712F1A5 for <dnsop@ietf.org>; Sat, 7 Jul 2018 05:05:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1530965107; x=1531569907; 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=05myFbCw 8wfKjF/JZuF016fQ197L7T3iFkgzytzo9V8=; b=sJm0c0DxAvoOo/xUO2/OIXXl nUBrWVtwuS7tWeCsqTBYEdjPRGTMs7IMuMW+eWRb7tFsDPbTz5z/X9qrtctLDY9t YINLeR3270379mptElkMlSxvX21gcf57Xx7u1yoLTH+ZUq1ZK6+pAZK63jK6h2zw 8fmnKrhH8HAFKX7/GRg=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Sat, 07 Jul 2018 14:05:07 +0200
X-Spam-Processed: mail.consulintel.es, Sat, 07 Jul 2018 14:05:06 +0200
Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005807974.msg for <dnsop@ietf.org>; Sat, 07 Jul 2018 14:05:05 +0200
X-MDRemoteIP: 2001:470:1f09:495:d455:dcec:2858:94d5
X-MDHelo: [10.10.10.99]
X-MDArrival-Date: Sat, 07 Jul 2018 14:05:05 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1726381e16=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: dnsop@ietf.org
User-Agent: Microsoft-MacOutlook/10.e.1.180613
Date: Sat, 07 Jul 2018 14:05:02 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: <dnsop@ietf.org>
Message-ID: <1D2DD97F-B9B9-4F55-8A9D-BE902D5333DC@consulintel.es>
Thread-Topic: [DNSOP] AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa
References: <m1fb194-0000FpC@stereo.hq.phicoh.net> <A61E2913-891E-4F14-82AF-A8A40F39F47F@isc.org> <m1fbMB8-0000FkC@stereo.hq.phicoh.net> <FA54B85D-EBD7-4852-86F2-672B918A96E1@isc.org> <m1fbMar-0000HxC@stereo.hq.phicoh.net>
In-Reply-To: <m1fbMar-0000HxC@stereo.hq.phicoh.net>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8pSQPeOHyckApjAQNK_TYP4A-AM>
Subject: Re: [DNSOP] AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Jul 2018 12:05:12 -0000

I agree that users changing DNS is a problem, but as said in my previous email the alternative is forcing DHCPv6 (and an option for that) as a MUST for any IPv6 implementation, or forcing a MUST for PCP support, so then RFC7225 can be used.



I see both of those two options as a utopia right now.



Operators should try to avoid impact on DNS changed by users, and the best way to sort that problem (in a bigger % of cases) is making sure that if DNS64 is not used, it still works, which means supporting CLAT.



I think I've described the case for that in draft-ietf-v6ops-nat64-deployment.



Another possible alternative is also to tell the host implementations that if they can't find a NAT64 prefix using RFC7050, they should try with the WKP 64:ff9b::/96.



May be is something to consider in draft-ietf-6man-rfc6434-bis ?



Regards,

Jordi

 

 



-----Mensaje original-----

De: DNSOP <dnsop-bounces@ietf.org> en nombre de Philip Homburg <pch-dnsop-3@u-1.phicoh.com>

Fecha: viernes, 6 de julio de 2018, 11:00

Para: <dnsop@ietf.org>

Asunto: Re: [DNSOP] AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa



    In your letter dated Fri, 6 Jul 2018 18:50:44 +1000 you wrote:

    >All it does is ensure that the DNS queries get to the DNS64 server. 

    

    The way RFC 7050 works that you send queries to your local recursive

    resolver. The problem there is that if the user manually configured

    a public recursive resolver then you don't learn the translation prefix.

    

    In this context I don't see how serving ipv4only.arpa from dedicated addresses

    would help. 

    

    We can define a new prefix discovery protocol where the node that needs to

    discover the prefix directly queries the authoritative servers for

    ipv4only.arpa. That would solved the issue with manually configured 

    resolvers. But it would also add yet another way off discovering the prefix

    that needs to be supported.

    

    

    _______________________________________________

    DNSOP mailing list

    DNSOP@ietf.org

    https://www.ietf.org/mailman/listinfo/dnsop

    




**********************************************
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.