IETF Logo Mail Archive

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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Sat, 07 July 2018 11:55 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 9216B130DBE for <dnsop@ietfa.amsl.com>; Sat, 7 Jul 2018 04:55:46 -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 v-tkYR95ldYI for <dnsop@ietfa.amsl.com>; Sat, 7 Jul 2018 04:55:44 -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 62E3812F1A5 for <dnsop@ietf.org>; Sat, 7 Jul 2018 04:55:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1530964542; x=1531569342; 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=fTDdTJJR xZvz5I2g8OULhoKpeVQJnc+vzyTD73YSGgk=; b=Xk2YwY/rzMOe9/JN0FazaIU2 Ypa7VjPfyOzurMNqfHTe0pHkXhgAfG/N1Tr2jOfuhs/Px4IViwwGl4dCfpMImkH1 PrmXTli+/S2L2IudvPuZ4shi5CI0XU0+2HKN7qv9dHCAImRhFyYVSk1biozFAeQG zYcjGBc8EkiYnArEeHU=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Sat, 07 Jul 2018 13:55:42 +0200
X-Spam-Processed: mail.consulintel.es, Sat, 07 Jul 2018 13:55:42 +0200
Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005807968.msg for <dnsop@ietf.org>; Sat, 07 Jul 2018 13:55:40 +0200
X-MDRemoteIP: 2001:470:1f09:495:d455:dcec:2858:94d5
X-MDHelo: [10.10.10.99]
X-MDArrival-Date: Sat, 07 Jul 2018 13:55:40 +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 13:55:37 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: dnsop@ietf.org
Message-ID: <39E95DEA-0A99-437D-8DCE-4FEA05572865@consulintel.es>
Thread-Topic: [DNSOP] AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa
References: <CAHw9_iK605yw--xE0NutaF=r+MfmmT2cBj9eNnSOh4Swkx=_QQ@mail.gmail.com> <m1fb194-0000FpC@stereo.hq.phicoh.net>
In-Reply-To: <m1fb194-0000FpC@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/S7Kl6pk1171OFI72-NMIosexl-I>
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 11:55:47 -0000

I think deprecating RFC7050 will be a bad idea, there are too many implementations that really need that, while updating APIs/libraries to make sure they comply with this seems easier.



For example, we could have a DHCPv6 option, but in the cellular world DHCPv6 is not used ... and even in non-cellular, Android is not using it either.



Regards,

Jordi

 

 



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

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

Fecha: jueves, 5 de julio de 2018, 12:06

Para: <dnsop@ietf.org>

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



    >draft-cheshire-sudn-ipv4only-dot-arpa document

    

    Section 7.1:

    "Name resolution APIs and libraries MUST recognize 'ipv4only.arpa' as

    "special and MUST give it special treatment. 

    

    It seems to me that it is going way to far to require all DNS software to

    implement support for a hack that abuses DNS for configuration management of

    a rather poor IPv4 transition technology.

    

    I think the more obvious approach is to formally deprecate RFC 7050 and

    require nodes that need to do NAT64 address synthesis use one of the other

    methods for obtaining the NAT64 prefix.

    

    The only part of the draft that makes sense to me is to make ipv4only.arpa

    an insecure delegation. 

    

    Any other problems are better solved by deprecating RFC 7050.

    

    _______________________________________________

    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.

v2.23.0 | Report a Bug | By Email