Re: Network merge [Re: RFC6724-bis?]

David Farmer <farmer@umn.edu> Tue, 27 September 2022 17:47 UTC

Return-Path: <farmer@umn.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42776C15A722 for <ipv6@ietfa.amsl.com>; Tue, 27 Sep 2022 10:47:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzWU4UYU-StA for <ipv6@ietfa.amsl.com>; Tue, 27 Sep 2022 10:47:32 -0700 (PDT)
Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10BE6C15AE1A for <ipv6@ietf.org>; Tue, 27 Sep 2022 10:47:32 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 4McRsb3YdRz9wPsR for <ipv6@ietf.org>; Tue, 27 Sep 2022 17:47:31 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u53lljmbfWQk for <ipv6@ietf.org>; Tue, 27 Sep 2022 12:47:31 -0500 (CDT)
Received: from mail-ej1-f72.google.com (mail-ej1-f72.google.com [209.85.218.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 4McRsX4xc8z9w944 for <ipv6@ietf.org>; Tue, 27 Sep 2022 12:47:28 -0500 (CDT)
DMARC-Filter: OpenDMARC Filter v1.3.2 mta-p5.oit.umn.edu 4McRsX4xc8z9w944
DKIM-Filter: OpenDKIM Filter v2.11.0 mta-p5.oit.umn.edu 4McRsX4xc8z9w944
Received: by mail-ej1-f72.google.com with SMTP id hr29-20020a1709073f9d00b0078333782c48so3329862ejc.10 for <ipv6@ietf.org>; Tue, 27 Sep 2022 10:47:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=fwxUI6p8k0OYKnrXAwCh1ut8Xeg1/wZQiX17y3tyXvc=; b=euRbrf7zRcIKXEuJWYZNDdFFiVm42OrEsf1zMfze7eQZEnywMnlExfcpVnQctAZ8Y3 8RCQA7bpxfUY0G7AhbSXNnGxwo7bf2u1EALdcPORy2dpMhCsEXG+ZdciwQFdEDhVWgjB WWEdaMTbZnaL59DM9UVwgXpV50yV7HDNPl/fZjjK11vvb7RD82gRMhP0JlVcovmvLeeQ HtfHCZD/UfhpPAV+rMy4A5ADltIPQrm/Ib0w3ot2AjY3+w/XAd1xzDbse2f9vmT4jgZ1 AxHLHgwiG4dPsMzJSnqGwEyLamGJYRLZpg9vBLtR4b2Vp9Y0jvjp4opOHBYWIP4PW29R 6slA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=fwxUI6p8k0OYKnrXAwCh1ut8Xeg1/wZQiX17y3tyXvc=; b=D4MP0ZMIdoYtz6ZdS4lROiSUxvXbdfGREzpgHUXcWOIec57nNwcrkJ1/rBV6dqXI3l d3C2cdy04P3A5uJilbGE7hNKgfNDW8g/qOdNYTSGj0LhJpx9+Bz6fEjatF7ZDOb52kfF RPiZaU8apqNFFytIh2dYqgrk+K8KvmdNxdbwhtW9lrWkIdl8qMKAfe45TemI+8Ijyd4Y OcawKzp+1tug0tbrAy7JC+U/ijREMwXMLa4ENV3QjwSBrqGcXGFhwecqE8LrPjMJXnGw I2kHB6dof4ZMj0DG2+iN31J20YTDmH8RPrC34SUZkZSsFuKEuyruwU/TuKeMQdxN3dBs PipA==
X-Gm-Message-State: ACrzQf0bWGnLS7UyZoKkYc9AoeAN0pErA3k7SYlY3xapm7Nub+R0PSY0 +/1/9/SpVetZBmI6PM1+emi8O3XNW8vERcv+M775KYZubxwQJb2wtwYEhjsIAGYE3SNPN5BLj0P Tc4KntYn2nGoKL8qa7L7kgeSg
X-Received: by 2002:a17:906:ef90:b0:77c:7227:705 with SMTP id ze16-20020a170906ef9000b0077c72270705mr23047818ejb.565.1664300841415; Tue, 27 Sep 2022 10:47:21 -0700 (PDT)
X-Google-Smtp-Source: AMsMyM62jI25+JmgPb3IpJJNf+5zrYl1Un+25dGGyrYTzqy+2aK4FqwevDrT+hFP9WVlzm3snkYQGReCQb/rhlLpXDI=
X-Received: by 2002:a17:906:ef90:b0:77c:7227:705 with SMTP id ze16-20020a170906ef9000b0077c72270705mr23047795ejb.565.1664300840999; Tue, 27 Sep 2022 10:47:20 -0700 (PDT)
MIME-Version: 1.0
References: <66892DC8-6DA4-4DC8-85B0-E1E1647CD9F7@gmail.com> <CAPt1N1=xR_2Xw+1KL6vbzZ69N+vonhcTNvO=DBceeApfoS2bMQ@mail.gmail.com> <e76267b6101146cf8a1bd6fa567c6b77@huawei.com> <CAN-Dau2QO5sxevJwUbOj+_wyiCdOjnPEZM14Jhevvkq4YZqU7Q@mail.gmail.com> <bc85e623-ef89-d2e2-4e33-b8ce0a4ec343@gmail.com> <CAN-Dau0Wbki6xwcEdy8ZK-pO9jeT6+8TKZgbmXWUgnkR+dRhBg@mail.gmail.com> <CAPt1N1=OmC+HNVGWbgj9JtGbpcuzKOgjZ1KXJm5mXgpji-G4Mw@mail.gmail.com> <6edcc5d8-edf1-51de-103c-a4ac6060fef6@gmail.com> <29689d645d22409b962f6c361d71e098@huawei.com> <CAN-Dau3rwi4X4NqLbHMmPQQ=i7y23Kz70JK09ggsXSxkJfT5xA@mail.gmail.com> <bf7c7d74cc7744ef8ded7d043ceb3e5e@huawei.com> <CAN-Dau0=LD9MTYKJQoSw=b9S25nmrNuqRSyLdsztFZscG8ZbUg@mail.gmail.com> <CAPt1N1kjOWh8R70pNO0eH9EJUH-v6HyxGMqxpy0N2hydHN33LQ@mail.gmail.com> <CAM5+tA9mqjrtq3pTggv1pA4fOYXUODkZHy74vs8cffVOrBefbQ@mail.gmail.com> <0b6886d3-5ea9-0a1d-8b16-4e17daeb6924@gmail.com> <CAM5+tA9dAjh0MTRG3922xTe3_aChHFa9AYCFCGmt395KwuvBYA@mail.gmail.com> <395554.1664189125@dooku> <56a897a426084f9381abaf770f1ea35e@huawei.com> <CAO42Z2xgMnVXeH9t0p_u7bg2fY-Gg+AagkFMMRJstX4E-f8FPQ@mail.gmail.com> <CAN-Dau0i2kEUEd1ESVg0qT4rosPhjpaeYDoyrE5mzALXWTtJXQ@mail.gmail.com> <9d0f017050f942a8aa130db859be549f@huawei.com>
In-Reply-To: <9d0f017050f942a8aa130db859be549f@huawei.com>
From: David Farmer <farmer@umn.edu>
Date: Tue, 27 Sep 2022 12:47:04 -0500
Message-ID: <CAN-Dau385HKHJL=LZJzxnX1ujH3eM71chA8prGNSP1zQVCfGDA@mail.gmail.com>
Subject: Re: Network merge [Re: RFC6724-bis?]
To: Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>
Cc: 6man WG <ipv6@ietf.org>, David Farmer <farmer=40umn.edu@dmarc.ietf.org>, Mark Smith <markzzzsmith@gmail.com>, Michael Richardson <mcr+ietf@sandelman.ca>
Content-Type: multipart/alternative; boundary="0000000000006d7c0b05e9ac3cf4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/yadJ2G1cAvvmVLWzG27VevwDNOo>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Sep 2022 17:47:36 -0000

On Tue, Sep 27, 2022 at 03:06 Vasilenko Eduard <vasilenko.eduard=
40huawei.com@dmarc.ietf.org> wrote:

> I do not understand the concern about DNS leakage outside of the ULA
> domain.
>
> For sure, it would happen again and again. People are making mistakes.
>
> But why it is a problem?
>
> Only resources of this domain may lose reachability from the outside.
>
> The one who made a mistake would be contacted and fix it.
>
> Ed/
>
>
First, not prioritizing remote ULAs is consistent with section 6,
Destination Address Selection, Rule 1: Avoid unusable destinations.  Most
ULAs will be unreachable and are therefore unusable, only the known local
ULAs have any realistic chance of being reachable and therefore usable.

Further, while ULAs in the global DNS are not recommended, they are not
prohibited either, and the “not recommended” in the controlling sentence of
section 4.4 of RFC4193 is explicitly not normative. The only normative
statement in that section is that reverse queries (PTR queries) MUST NOT be
sent to DNS Servers for the global DNS because of the excessive load they
can create. However, the AS112 project, as described in RFC 7534, now
handles this issue, so even that normative statement is probably obsolete,
or at least no longer absolutely necessary.

And even if it was normatively “NOT RECOMMENDED” to put ULAs in the global
DNS, per RFC 2119, “there may exist valid reasons in particular
circumstances when the particular behavior is acceptable or even useful.”

Therefore, there probably exist situations where ULAs in the global DNS
could be acceptable, and it is therefore probably a good idea to at least
account for this possibility when considering the appropriate priority for
ULAs, and the current version of RFC 6724 does just that,

Thanks.

*From:* David Farmer [mailto:farmer=40umn.edu@dmarc.ietf.org
> *Sent:* Tuesday, September 27, 2022 3:15 AM
> *To:* Mark Smith <markzzzsmith@gmail.com>
> *Cc:* 6man WG <ipv6@ietf.org>; Michael Richardson <mcr+ietf@sandelman.ca>;
> Vasilenko Eduard <vasilenko.eduard@huawei.com>
> *Subject:* Re: Network merge [Re: RFC6724-bis?]
>
>
>
>
>
>
>
> On Mon, Sep 26, 2022 at 18:17 Mark Smith <markzzzsmith@gmail.com> wrote:
>
>
> Define another flag if this is going to be the solution to the fault of
> putting ULA AAAAs in global DNS.
>
>
>
> (Can it be adapted to the fault of putting link-local addresses in DNS?)
>
>
>
> ULAs in the global DNS, are only one of several faults that is being
> worked around with this admitted hack.  Another is the lose or even
> nonexistent boundary controls between the local and global domains in most
> networks, especially unmanaged networks, which can expose local information
> more widely than expected by most users. This is all further exasperated by
> the lack of any precise definition of what local means, and the very
> concept a globally scoped local address only adds to this confusion.
>
>
>
> A sign that it's not solving the problem where it exists.
>
>
>
> The problems exists in my places.
>
>
>
>
>
>
>
> --
>
> ===============================================
> David Farmer               Email:farmer@umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE
> <https://www.google.com/maps/search/2218+University+Ave+SE?entry=gmail&source=g>
>       Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>