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

Vasilenko Eduard <vasilenko.eduard@huawei.com> Tue, 27 September 2022 13:57 UTC

Return-Path: <vasilenko.eduard@huawei.com>
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 CEFAFC1526FD for <ipv6@ietfa.amsl.com>; Tue, 27 Sep 2022 06:57:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 RdTdHIlCICtk for <ipv6@ietfa.amsl.com>; Tue, 27 Sep 2022 06:57:32 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 363E6C152567 for <ipv6@ietf.org>; Tue, 27 Sep 2022 06:57:32 -0700 (PDT)
Received: from fraeml745-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4McLkm1X5Lz688hK; Tue, 27 Sep 2022 21:56:16 +0800 (CST)
Received: from mscpeml500002.china.huawei.com (7.188.26.138) by fraeml745-chm.china.huawei.com (10.206.15.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Tue, 27 Sep 2022 15:57:28 +0200
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml500002.china.huawei.com (7.188.26.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Tue, 27 Sep 2022 16:57:28 +0300
Received: from mscpeml500001.china.huawei.com ([7.188.26.142]) by mscpeml500001.china.huawei.com ([7.188.26.142]) with mapi id 15.01.2375.031; Tue, 27 Sep 2022 16:57:28 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, 6man WG <ipv6@ietf.org>
Subject: RE: Network merge [Re: RFC6724-bis?]
Thread-Topic: Network merge [Re: RFC6724-bis?]
Thread-Index: AQHY0FWzi1mPXFg/Y0GQt/hCVGqTN63wdgWAgADrAlD///YugIAAOJuQgACZh4CAAA/1AIAAtQyggAArDoCAADQ94A==
Date: Tue, 27 Sep 2022 13:57:28 +0000
Message-ID: <b771452b9202459d835a9675d3ab1b86@huawei.com>
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> <56a8 97a426084f9381abaf770f1ea35e@huawei.com> <CAO42Z2xgMnVXeH9t0p_u7bg2fY-Gg+AagkFMMRJstX4E-f8FPQ@mail.gmail.com> <CAN-Dau0i2kEUEd1ESVg0qT4rosPhjpaeYDoyrE5mzALXWTtJXQ@mail.gmail.com> <9d0f017050f942a8aa130db859be549f@huawei.com> <263962.1664285803@dooku>
In-Reply-To: <263962.1664285803@dooku>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.144.28]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/RuvSubYMDY2weq9egvnVsvNZj5w>
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 13:57:34 -0000

VPN from the host is not relevant to our discussion, because it creates a separate interface (with separate scope). It is easy for the host to play completely independently on different interfaces connected to different networks, including DNS (no need for PvD).
Challenges may arise only on one interface.

I have not understood why the leakage of ULA into the Internet is a feature.
What is the scenario when it may be useful?

RFC 4193 section 4.4:
AAAA and PTR records for locally assigned local IPv6 addresses are not recommended to be installed in the global DNS
Reverse (address-to-name) queries for locally assigned IPv6 Local addresses MUST NOT be sent to name servers for the global DNS

Section 4.6:
Nodes with only Local IPv6 addresses must not be installed in the global DNS
Nodes that are to be reachable from inside of the site and from
        outside of the site:  The DNS should be configured to include
        the global addresses of these nodes.  The local DNS may be
        configured to also include the Local IPv6 addresses of these
        nodes.

Ed/
-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Michael Richardson
Sent: Tuesday, September 27, 2022 4:37 PM
To: 6man WG <ipv6@ietf.org>
Subject: Re: Network merge [Re: RFC6724-bis?]


please stop top-quoting.

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

Being able to put site-specific addresses into DNS is, in my opinion, one of the features of IPv6 and ULA which IPv4+RFC1918 lack.

It's not a mistake or a bug.  It's a feature.

In order to keep end systems at other sites from wasting time trying to reach addresses which are never going to reachable, we should not prioritize fc00::/7, but /48s which are directly connected in some fashion.
(Both from RIOs, PIOs, but also VPN systems)

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works  -= IPv6 IoT consulting =-