IETF Logo Mail Archive

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

Ole Troan <otroan@employees.org> Tue, 27 September 2022 21:41 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 81914C157B45 for <ipv6@ietfa.amsl.com>; Tue, 27 Sep 2022 14:41:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.513
X-Spam-Level:
X-Spam-Status: No, score=-3.513 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, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_DNSWL_MED=-2.3, 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=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 zoqtRttqnskI for <ipv6@ietfa.amsl.com>; Tue, 27 Sep 2022 14:41:30 -0700 (PDT)
Received: from vesa01.kjsl.com (vesa01.kjsl.com [IPv6:2607:7c80:54:6::11]) (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 A6697C1526FB for <ipv6@ietf.org>; Tue, 27 Sep 2022 14:41:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=employees.org; i=@employees.org; q=dns/txt; s=vesa202009; t=1664314890; x=1695850890; h=content-transfer-encoding:from:mime-version:subject:date: message-id:references:cc:in-reply-to:to; bh=yZWKIfzLuNmD+5htMfTyCmfwtPJuJ1CO3Bp13ns+hA4=; b=EKx4Giq16Ur4JwXiDGDD4cIalv8OLJtNvm7MOIOUVZ4PWvP8Hjd6aXhv 9KA9ynMQRxo3ntpxitb8p0QZcDhL3GhsxWwprv0zHK+3sGhfO+2SBfsf8 Dq/N615s/806tJ5J7YxLeJYFdpCLqGjxY2+osNOXMqgqLds7DljKG//V/ acn7GENZL6aKKu+vV06wb5oBlZyUoeW/yqOAWta5fUPoYE+4LiBB5/x7f P665Lo1ohXVsawHv8Ptfpg9ID/f8bajeUgkcISECJZI6qGHaHBlPbRWUY N5pXOCXoZA5q/3SQ9UCQ1XpLq8VmMNpYpHZDPnt0ew4D509hT5Su9+2kr g==;
Received: from clarinet.employees.org ([198.137.202.74]) by vesa01.kjsl.com with ESMTP; 27 Sep 2022 21:41:30 +0000
Received: from smtpclient.apple (unknown [IPv6:2a02:2121:342:e33f:c12e:408e:3903:a97c]) (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 CCBBA4E11A33; Tue, 27 Sep 2022 21:41:29 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail-539B3589-2A99-4C5F-A67D-DE6C4FF8922D"
Content-Transfer-Encoding: 7bit
From: Ole Troan <otroan@employees.org>
Mime-Version: 1.0 (1.0)
Subject: Re: Network merge [Re: RFC6724-bis?]
Date: Tue, 27 Sep 2022 23:39:46 +0200
Message-Id: <2B72ABFE-E691-4F02-80E8-072B1CD698DE@employees.org>
References: <CANMZLAbUDV8pU6ge9fXnLMBF-TgP0N4az64z7N6_hM3siJbrBQ@mail.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: <CANMZLAbUDV8pU6ge9fXnLMBF-TgP0N4az64z7N6_hM3siJbrBQ@mail.gmail.com>
To: Brian Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: iPhone Mail (20A380)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/riewimw09IKUvL04xKeO14aBhWg>
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 21:41:34 -0000



On 27 Sep 2022, at 23:32, Brian Carpenter <brian.e.carpenter@gmail.com> wrote:


End of section 2.1

That would be a stretch.

Regardlessly if we agree on what the existing standards say or not. The proponents of this need to look at the consequences of overloading the protocol and why this is better than just using 7078.

O. 



Regards,
    Brian Carpenter
    (via tiny screen & keyboard)
   

On Wed, 28 Sep 2022, 09:57 Ole Troan, <otroan@employees.org> wrote:

RFC8028

Isn’t that a host behavior document?
Could not find where that changes router behavior.

O. 



Regards,
    Brian Carpenter
    (via tiny screen & keyboard)
   

On Wed, 28 Sep 2022, 09:00 Ole Troan, <otroan@employees.org> wrote:


> 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