IETF Logo Mail Archive

Re: [Add] DDR and 6to4

Tommy Pauly <tpauly@apple.com> Tue, 25 January 2022 16:24 UTC

Return-Path: <tpauly@apple.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78003A0EFC; Tue, 25 Jan 2022 08:24:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.674
X-Spam-Level:
X-Spam-Status: No, score=-7.674 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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=apple.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 T1pQOmpBqs9x; Tue, 25 Jan 2022 08:24:38 -0800 (PST)
Received: from rn-mailsvcp-ppex-lapp45.apple.com (rn-mailsvcp-ppex-lapp45.rno.apple.com [17.179.253.49]) (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 6B4DB3A0EF6; Tue, 25 Jan 2022 08:24:38 -0800 (PST)
Received: from pps.filterd (rn-mailsvcp-ppex-lapp45.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp45.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 20PG4lbf011447; Tue, 25 Jan 2022 08:24:38 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=tzlp/1gvcrUdtbb2B1kSJKBMrEX/pjHvKzNO9qZeBbg=; b=MwsABf1k0A5LOyHDPCeqkPW6KIcCkPv/ivxtZEGlxqxgw5avV/DMKWu4YNZW9mk+uhEl MlotjYbIuxSlx1LuzjBgRxlTHLqHnxxb/9DA/EYAItd+OYVHms1SuDKwSoQtgJj/ifQd 3s1dxA8j9tz4nvTzKvJV3eNrhamLFGnflmKq0svdDp1rc+3ZkjCGpoV6FlypZ+uEyQH4 bs/vazH8iv5riGJeHY3dSm13BeMDyleh5R/ewhDBFswRfE2pEJsBc8fivkgc5SDMbApD tbHZqqXoHUgStemirtQ13NwgFCWb1EbspsUmYHa/G/fMzAXKT4nL4QBlw0g7nUuTafEB hA==
Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by rn-mailsvcp-ppex-lapp45.rno.apple.com with ESMTP id 3drh3w0cvw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 25 Jan 2022 08:24:38 -0800
Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R6900MSXXKJHXI0@rn-mailsvcp-mta-lapp04.rno.apple.com>; Tue, 25 Jan 2022 08:24:19 -0800 (PST)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R6900A00XFRA700@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 25 Jan 2022 08:24:19 -0800 (PST)
X-Va-A:
X-Va-T-CD: d961ed54a37a0e7c98140a093d4f1762
X-Va-E-CD: 974dd7ae78db809db082eaa95254ebda
X-Va-R-CD: 5d91c8a21e2c3640798e041ce6a6b26b
X-Va-CD: 0
X-Va-ID: 2d886bec-3006-444b-86c9-f0d2a17a6da0
X-V-A:
X-V-T-CD: d961ed54a37a0e7c98140a093d4f1762
X-V-E-CD: 974dd7ae78db809db082eaa95254ebda
X-V-R-CD: 5d91c8a21e2c3640798e041ce6a6b26b
X-V-CD: 0
X-V-ID: eb4274a7-ac2b-47f1-a873-b033d8a18f8f
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.816 definitions=2022-01-25_03:2022-01-25, 2022-01-25 signatures=0
Received: from smtpclient.apple (unknown [17.234.35.173]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R6900G0ZXKIDD00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 25 Jan 2022 08:24:19 -0800 (PST)
From: Tommy Pauly <tpauly@apple.com>
Message-id: <8FB9E809-F212-4A2E-9394-77BF7FBA933E@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_17EEC383-B1D5-43FB-8437-58B6A59AEF16"
MIME-version: 1.0 (Mac OS X Mail 15.0 \(3691.0.3\))
Date: Tue, 25 Jan 2022 08:24:18 -0800
In-reply-to: <DE480E22-CEAD-4CB5-9136-B4B4EF9C13AF@cisco.com>
Cc: Tommy Jensen <Jensen.Thomas=40microsoft.com@dmarc.ietf.org>, ADD Mailing list <add@ietf.org>
To: "Eric Vyncke (evyncke)" <evyncke=40cisco.com@dmarc.ietf.org>
References: <DE480E22-CEAD-4CB5-9136-B4B4EF9C13AF@cisco.com>
X-Mailer: Apple Mail (2.3691.0.3)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.816 definitions=2022-01-25_03:2022-01-25, 2022-01-25 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/iRprpJWhvjdzexlBAS9snzajQzg>
Subject: Re: [Add] DDR and 6to4
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2022 16:24:43 -0000

Like Eric, I’d also lean towards not saying anything in the DDR spec about these specific address types.

Tommy (Pauly)

> On Jan 24, 2022, at 1:29 AM, Eric Vyncke (evyncke) <evyncke=40cisco.com@dmarc.ietf.org> wrote:
> 
> Tommy,
>  
> Wearing no hat at all, isn't this 6to4 address issue completely orthogonal to DDR SVCB or even to ADD ? I.e., IMHO let's not mention anything about 6to4 addresses in our WG documents, else should we also say something about IPv6 ULA ? :-)
>  
> Regards
>  
> -éric
>  
> From: Add <add-bounces@ietf.org> on behalf of Tommy Jensen <Jensen.Thomas=40microsoft.com@dmarc.ietf.org>
> Date: Wednesday, 19 January 2022 at 03:27
> To: ADD Mailing list <add@ietf.org>
> Subject: [Add] DDR and 6to4
>  
> What does everyone think about actively discouraging the use of 6to4 addresses in the DDR SVCB records? I know this is covered by RFC7526; is that sufficient for us to omit text in DDR? Should we reference it and require resolvers to not provide those addresses? It seems there are some edge cases where a client and resolver may disagree about the nature of a given IP address if these are designated.
>  
> Thanks,
> Tommy
> -- 
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add

v2.23.0 | Report a Bug | By Email