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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 27 September 2022 19:32 UTC

Return-Path: <brian.e.carpenter@gmail.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 2F17DC15DD6C for <ipv6@ietfa.amsl.com>; Tue, 27 Sep 2022 12:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 LYPPog_RvF7V for <ipv6@ietfa.amsl.com>; Tue, 27 Sep 2022 12:32:10 -0700 (PDT)
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EE9BC15DD6D for <ipv6@ietf.org>; Tue, 27 Sep 2022 12:32:10 -0700 (PDT)
Received: by mail-pl1-x62b.google.com with SMTP id w20so9947755ply.12 for <ipv6@ietf.org>; Tue, 27 Sep 2022 12:32:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date; bh=vtcPPPCG5cwVVGoPjNhGMAcgAvNXfa6b3YzpWNOFuac=; b=T8UcQtAe7nml3MsdlxXTuKhmVTFNLS3ONqQ/TdMc3h1TmWouxYyfHaVMnh266vsV02 1cdPu+TP7feUz5R5MWu299wDtOIM0X2ZXVJIFWQnysofSSLD2CiS1IjjuVU6FmIKmA0x pLnOE6ObpmAnmx9VgCFb7KIzbJjAtHQ4Wa+BscU3eAUKVdkfQ5/kK6Kq8ziGQ1zZq6rY tSEFrKe/6C+O+movZMbEoWeG96bdTmjxe437lohl1mfIZNrtEtF5NiOunkQHAoOo/USj LIRh4ZSePUKe9/wKd29yAUeRJf3VLD+k16gC1j1KvBzP+FtXTphk5KbSWyHy4Jvr6Mdk eLzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=vtcPPPCG5cwVVGoPjNhGMAcgAvNXfa6b3YzpWNOFuac=; b=1O9PLQvj12p1SkO0eLlIGqVwbTk2RECeX/v2sAplVisei3XQgwsKZ66Ny1DeY2xpGj KWze2KaSKM8GoCNxDxLq0njQ/UYozNecsU2A+yDtq0uI+rqGqqA4T3/5HZZXyt9GxvlK /Jwm3EnDW83yLEmZveIq9bRalMujCy7vgyCCdlhD35Ou++cxwh1ZX7Um35tvicYiWRKv 3yjFUwMq5xMBfsIXjRYqShOyso0quKsm9sl6EsbDq4/zffndM6YsRJVmwS0dUfk8Y19q Sx1gXnbGEfDDSvnsbw+n6ja6PJUjEkX8qVD+GT2F1DIvYknU7DPV7Ds5O7C6exzXNGv5 0CPA==
X-Gm-Message-State: ACrzQf02urPXsKqVmmZk9bPLLv22UORre6/xf+jfs3m4AZwrqFOpiHqG 5laYWc81+v/b7Y47bg43STw=
X-Google-Smtp-Source: AMsMyM4g6Q7AR9PR1ivfgQEvDJ4DE8Dlb1nYBFNBgnrX1PsjqZE/llT31hjM4QTex8QAisai+ToKaA==
X-Received: by 2002:a17:90a:ce8a:b0:203:7b48:dcdf with SMTP id g10-20020a17090ace8a00b002037b48dcdfmr6348439pju.12.1664307129629; Tue, 27 Sep 2022 12:32:09 -0700 (PDT)
Received: from ?IPV6:2406:e003:1124:9301:80b2:5c79:2266:e431? ([2406:e003:1124:9301:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id k60-20020a17090a4cc200b002006f15ad4fsm8785670pjh.10.2022.09.27.12.32.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Sep 2022 12:32:08 -0700 (PDT)
Message-ID: <33031a7e-c099-e660-3575-12d45854604e@gmail.com>
Date: Wed, 28 Sep 2022 08:32:03 +1300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Subject: Re: Network merge [Re: RFC6724-bis?]
Content-Language: en-US
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>, Mark Smith <markzzzsmith@gmail.com>, Ted Lemon <mellon@fugue.com>
Cc: 6man WG <ipv6@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>
References: <66892DC8-6DA4-4DC8-85B0-E1E1647CD9F7@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> <CAPt1N1m-1600rghA7mXNm1fvqOp23EOpYcS0E6xnJut+-t-9nQ@mail.gmail.com> <CAO42Z2wHZ2k+UwRdh8VH4xHav9HwT+6C-_up+6RXrce3vuVrmg@mail.gmail.com> <09adb05f-4c2b-1f76-fed7-58fbfa9c2f3f@gmail.com> <be14b944395c4dd694ded6c9033790ab@huawei.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <be14b944395c4dd694ded6c9033790ab@huawei.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/k5h1Oo2ixCRDWILfxpHsmInXeIM>
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 19:32:12 -0000

> It is proposed here to have hundreds of PIOs

No. Just one per router, and only when there is a new ULA prefix in scope after a network merge.

(It is the presence of a ULA /48 prefix in local routing that we care about. The PIO for a /64 within that /48 is the trigger that it needs high precedence.)

Regards
    Brian Carpenter

On 27-Sep-22 21:02, Vasilenko Eduard wrote:
> I am not so scared "on every interface". It is not good too (no automation), but tolerable for the Enterprise environment, not tolerable for SMB/home.
> 
> If I understand the context of this discussion (I am not sure)
> It is proposed here to have hundreds of PIOs (A=L=0) on every interface! (separate prefix announcement for every remote prefix on different links)
> It looks like the consequence of /64 ULA policy table modification instead of /48 (A=L=0 PIO looks for this, right?).
> If my guess is right - then it is terrible.
> 
> Eduard
> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> Sent: Tuesday, September 27, 2022 7:39 AM
> To: Mark Smith <markzzzsmith@gmail.com>; Ted Lemon <mellon@fugue.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 27-Sep-22 17:02, Mark Smith wrote:
>>
>>
>> On Tue, 27 Sept 2022, 09:46 Ted Lemon, <mellon@fugue.com <mailto:mellon@fugue.com>> wrote:
>>
>>      The use case we are talking about here is a managed enterprise network. It should be no problem for the network operator to configure some local ra options.
>>
>>
>> On every existing and every new internal interface of every router in the network?
> 
> Yes, but I assume that enterprises need ways to do network-wide config anyway. If not, that's why we're working on autonomic networking, to provide an ecosystem for smart enterprise-wide config.
>    
>> For many networks that's 100s if not 1000s of interfaces to configure with this parameter. That's a lot of work for *every* enterprise network to perform to work around somebody else's occasional error of putting ULA AAAAs in global DNS.
> 
> I can't disagree (but it suggests a big gap in DNS tooling if that's even allowed except inside a split horizon DNS).
> 
>      Brian
> 
>>
>> This work around is going to be far more costly than teaching people not to put ULA AAAAs in global DNS.
>>
>> You don't teach people not to do something bad by hiding the consequences when they do, and placing the costs of tolerating that bad behaviour onto everybody else other than the person who created the problem.
>>
>> Regards,
>> Mark.
>>
>>
>>      Op ma 26 sep. 2022 om 19:17 schreef Mark Smith <markzzzsmith@gmail.com <mailto:markzzzsmith@gmail.com>>
>>
>>
>>
>>          On Mon, 26 Sept 2022, 21:15 Vasilenko Eduard, <vasilenko.eduard=40huawei.com@dmarc.ietf.org <mailto:40huawei.com@dmarc.ietf.org>> wrote:
>>
>>               >    > But how remote ULA prefix would be known to the local router?  If
>>               >It can't, which is fine.
>>               >If there are multiple ULAs after a merger, then we do what Brian and David described and send RIOs or PIOs.
>>
>>              It is evident that A=0 is for something non-local.
>>
>>
>>          A=0 means the opposite of A=1, and A=1 has a specific meaning, nothing to do with non-local.
>>
>>          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?)
>>
>>
>>              It would be especially needed if /64 would be put into the SASA policy table (then the remote prefix would be /64 too).
>>              It may be needed for different /48 after the company merge.
>>
>>              How to know what to put in this special PIO (A=L=0)? It looks like not automated at all.
>>
>>
>>          A sign that it's not solving the problem where it exists.
>>
>>
>>
>>              Ed/
>>              -----Original Message-----
>>              From: Michael Richardson [mailto:mcr+ietf@sandelman.ca <mailto:mcr%2Bietf@sandelman.ca>]
>>              Sent: Monday, September 26, 2022 1:45 PM
>>              To: Vasilenko Eduard <vasilenko.eduard@huawei.com <mailto:vasilenko.eduard@huawei.com>>; 6man WG <ipv6@ietf.org <mailto:ipv6@ietf.org>>
>>              Subject: Re: Network merge [Re: RFC6724-bis?]
>>
>>
>>              Vasilenko Eduard <vasilenko.eduard@huawei.com <mailto:vasilenko.eduard@huawei.com>> wrote:
>>                   >> Now as to how to fix this without a global precedence for ULAs, I am
>>                   >> wondering about a PIO with L=0 and A=0 (exactly as recommended in RFC
>>                   >> 8028, but for other reasons). If a host sees such a PIO for a ULA
>>                   >> prefix, it could serve as a signal that the prefix is to be given a
>>                   >> suitable precedence, even though it is not on-link and not used for
>>                   >> SLAAC.
>>
>>                   >> I really like this.  I think it is the best solution.
>>
>>                   > But how remote ULA prefix would be known to the local router?  If
>>
>>              It can't, which is fine.
>>
>>              If there are multiple ULAs after a merger, then we do what Brian and David described and send RIOs or PIOs.
>>
>>                   > proper routing is in place then no problem exists in the first place,
>>                   > the whole FC/7 could be prioritized.
>>
>>              I don't think that non-local ULAs *should* be prioritized.
>>              I think that it's actually a problem as more and more sites use ULA for significant internal things, and those addresses leak into other sites.
>>
>>
>>              --
>>              Michael Richardson <mcr+IETF@sandelman.ca <mailto:mcr%2BIETF@sandelman.ca>>, Sandelman Software Works  -= IPv6 IoT consulting =-
>>
>>
>>
>>              --------------------------------------------------------------------
>>              IETF IPv6 working group mailing list
>>              ipv6@ietf.org <mailto:ipv6@ietf.org>
>>              Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>>              --------------------------------------------------------------------
>>
>>          --------------------------------------------------------------------
>>          IETF IPv6 working group mailing list
>>          ipv6@ietf.org <mailto:ipv6@ietf.org>
>>          Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>>          --------------------------------------------------------------------
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------