IETF Logo Mail Archive

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

Ole Troan <otroan@employees.org> Tue, 27 September 2022 20:04 UTC

Return-Path: <otroan@employees.org>
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 C1554C14F727 for <ipv6@ietfa.amsl.com>; Tue, 27 Sep 2022 13:04:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.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, 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_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=employees.org
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 aTUvW3sfRjKf for <ipv6@ietfa.amsl.com>; Tue, 27 Sep 2022 13:04:45 -0700 (PDT)
Received: from vesa02.kjsl.com (vesa02.kjsl.com [IPv6:2620:13b:0:1000::10]) (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 CA647C15DD72 for <ipv6@ietf.org>; Tue, 27 Sep 2022 13:00:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=employees.org; i=@employees.org; q=dns/txt; s=vesa202009; t=1664308835; x=1695844835; h=content-transfer-encoding:from:mime-version:subject:date: message-id:references:cc:in-reply-to:to; bh=ExZpOBoUvQf2Bk1AA7Y8iP0bz7N2RFBRoJZulPsqXYI=; b=W5j3nH0eQe63lFxVoyfz0LgvCWbFOfQ0EScC26aSjv2xCtKWxMqVP6/9 fpXCKj94otjaciojg4g5nNW23RPKXYCe4TIQ0Tu/Udp9WemTwmb9jEV3r Vci+pYLTmIbQSVP/Q05QtQCMdu1fwfIH02XnwGKws52FVSh8YJ0lhr6Fs DgWDws7iznWyKHP6G6fcSozK9kr+wv/OmElXFt1Vvpy0mEZtEY0UI1Br/ ycz70tQFLA6NcnxFAU7Kh15EE9ba/JgcL+XO8vighoEIVB5fIPTtDZheK k694Tjn+iONZG48uldlZVKCpLvIzr28HRMFpK4W8EdVv3Gtmjai83mc3u w==;
Received: from clarinet.employees.org ([198.137.202.74]) by vesa02.kjsl.com with ESMTP; 27 Sep 2022 20:00:33 +0000
Received: from smtpclient.apple (ti0389q160-5451.bb.online.no [95.34.1.139]) (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 clarinet.employees.org (Postfix) with ESMTPSA id 7BB3E4E11B6C; Tue, 27 Sep 2022 20:00:33 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Ole Troan <otroan@employees.org>
Mime-Version: 1.0 (1.0)
Subject: Re: Network merge [Re: RFC6724-bis?]
Date: Tue, 27 Sep 2022 22:00:21 +0200
Message-Id: <C7A2356F-620F-4DE9-A848-5D6BF71A7DDC@employees.org>
References: <a55ec35e-1e98-5447-09aa-cf03d98d6e44@gmail.com>
Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com>, Mark Smith <markzzzsmith@gmail.com>, Ted Lemon <mellon@fugue.com>, 6man WG <ipv6@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>
In-Reply-To: <a55ec35e-1e98-5447-09aa-cf03d98d6e44@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: iPhone Mail (20A380)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/sXNTMM8owJ73YzmjrrFUagj0jpo>
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 20:04:49 -0000


> On 27 Sep 2022, at 21:48, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> On 28-Sep-22 08:40, Ole Troan wrote:
>>> (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.)
>> Extending and overloading existing protocol fields is problematic. The proponents of this need at least to consider the consequences for existing implementations and future extensibility of the protocol. As well as the deployability of this, compared to existing standardized solutions.
> 
> There isn't a standardized solution, since the mechanism for updating the RFC6724 table is not standardized. A=L=0 is already standardized to mean "I can route this prefix" and the proposal builds on that exact semantic.

Can you point to text stating that a PIO with A=L=0 in an RA from a router is a promise by that router to forward traffic for those prefixes? Or that a PIO has that semantic in any context. 

Rfc7078?

O.

v2.23.0 | Report a Bug | By Email