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 > -------------------------------------------------------------------- >
- RFC6724-bis? Tim Chown
- RE: RFC6724-bis? Vasilenko Eduard
- Re: RFC6724-bis? Brian E Carpenter
- Re: RFC6724-bis? Brian E Carpenter
- Re: RFC6724-bis? Nick Buraglio
- Re: RFC6724-bis? Brian E Carpenter
- Re: RFC6724-bis? Nick Buraglio
- RE: RFC6724-bis? Vasilenko Eduard
- Re: RFC6724-bis? Nick Buraglio
- Re: RFC6724-bis? Nick Buraglio
- Re: RFC6724-bis? Tim Chown
- Re: RFC6724-bis? Nick Buraglio
- Re: RFC6724-bis? Nick Buraglio
- Re: RFC6724-bis? Bob Hinden
- Re: RFC6724-bis? Brian E Carpenter
- RE: RFC6724-bis? Vasilenko Eduard
- Re: RFC6724-bis? Ted Lemon
- RE: RFC6724-bis? Vasilenko Eduard
- Re: RFC6724-bis? Mark Smith
- Re: RFC6724-bis? Ted Lemon
- RE: RFC6724-bis? Vasilenko Eduard
- Re: RFC6724-bis? Ted Lemon
- RE: RFC6724-bis? Vasilenko Eduard
- Re: RFC6724-bis? Michael Richardson
- Re: RFC6724-bis? David Farmer
- RE: RFC6724-bis? Vasilenko Eduard
- RE: RFC6724-bis? Vasilenko Eduard
- Re: RFC6724-bis? Michael Richardson
- Re: RFC6724-bis? Ted Lemon
- Re: RFC6724-bis? Brian E Carpenter
- Re: RFC6724-bis? Brian E Carpenter
- Re: RFC6724-bis? Brian E Carpenter
- Re: RFC6724-bis? Ted Lemon
- Re: RFC6724-bis? Mark Smith
- Re: RFC6724-bis? Ted Lemon
- Re: RFC6724-bis? David Farmer
- Re: RFC6724-bis? Ted Lemon
- Re: RFC6724-bis? Brian E Carpenter
- RE: RFC6724-bis? Vasilenko Eduard
- Re: RFC6724-bis? David Farmer
- RE: RFC6724-bis? Vasilenko Eduard
- Re: RFC6724-bis? Ted Lemon
- RE: RFC6724-bis? Vasilenko Eduard
- Re: RFC6724-bis? Nick Buraglio
- Re: RFC6724-bis? Ted Lemon
- RE: RFC6724-bis? Vasilenko Eduard
- Re: RFC6724-bis? Ted Lemon
- Re: RFC6724-bis? David Farmer
- Re: RFC6724-bis? Ted Lemon
- Re: RFC6724-bis? Nick Buraglio
- Re: RFC6724-bis? Brian E Carpenter
- Re: RFC6724-bis? Nick Buraglio
- Network merge [Re: RFC6724-bis?] Brian E Carpenter
- Re: Network merge [Re: RFC6724-bis?] David Farmer
- Re: Network merge [Re: RFC6724-bis?] Michael Richardson
- RE: Network merge [Re: RFC6724-bis?] Vasilenko Eduard
- Re: Network merge [Re: RFC6724-bis?] Brian Carpenter
- RE: Network merge [Re: RFC6724-bis?] Vasilenko Eduard
- RE: Network merge [Re: RFC6724-bis?] Vasilenko Eduard
- RE: Network merge [Re: RFC6724-bis?] Vasilenko Eduard
- RE: RFC6724-bis? Vasilenko Eduard
- RE: RFC6724-bis? Vasilenko Eduard
- Re: Network merge [Re: RFC6724-bis?] Michael Richardson
- RE: Network merge [Re: RFC6724-bis?] Vasilenko Eduard
- Re: Network merge [Re: RFC6724-bis?] Nick Buraglio
- Re: Network merge [Re: RFC6724-bis?] Brian E Carpenter
- Re: Network merge [Re: RFC6724-bis?] Mark Smith
- Re: Network merge [Re: RFC6724-bis?] Ted Lemon
- Re: Network merge [Re: RFC6724-bis?] David Farmer
- Re: Network merge [Re: RFC6724-bis?] Brian E Carpenter
- Re: Network merge [Re: RFC6724-bis?] Mark Smith
- Re: Network merge [Re: RFC6724-bis?] Brian E Carpenter
- RE: Network merge [Re: RFC6724-bis?] Vasilenko Eduard
- RE: Network merge [Re: RFC6724-bis?] Vasilenko Eduard
- Re: Network merge [Re: RFC6724-bis?] Michael Richardson
- RE: Network merge [Re: RFC6724-bis?] Vasilenko Eduard
- Re: Network merge [Re: RFC6724-bis?] David Farmer
- RE: Network merge [Re: RFC6724-bis?] Vasilenko Eduard
- Re: Network merge [Re: RFC6724-bis?] David Farmer
- RE: Network merge [Re: RFC6724-bis?] Vasilenko Eduard
- Re: Network merge [Re: RFC6724-bis?] Brian E Carpenter
- Re: Network merge [Re: RFC6724-bis?] Ole Troan
- Re: Network merge [Re: RFC6724-bis?] Brian E Carpenter
- RE: Network merge [Re: RFC6724-bis?] Vasilenko Eduard
- Re: Network merge [Re: RFC6724-bis?] Ole Troan
- Re: Network merge [Re: RFC6724-bis?] Timothy Winters
- Re: Network merge [Re: RFC6724-bis?] Nick Buraglio
- Re: Network merge [Re: RFC6724-bis?] Brian Carpenter
- Re: Network merge [Re: RFC6724-bis?] Ole Troan
- Re: Network merge [Re: RFC6724-bis?] Brian Carpenter
- Re: Network merge [Re: RFC6724-bis?] Ole Troan
- Re: Network merge [Re: RFC6724-bis?] David Farmer
- Re: Network merge [Re: RFC6724-bis?] Brian E Carpenter
- Re: Network merge [Re: RFC6724-bis?] Michael Richardson
- Re: Network merge [Re: RFC6724-bis?] Ted Lemon
- RE: RFC6724-bis? Vasilenko Eduard
- Re: RFC6724-bis? Ted Lemon
- Re: RFC6724-bis? Ted Lemon
- Re: RFC6724-bis? Nick Buraglio
- Re: RFC6724-bis? Michael Richardson