IETF Logo Mail Archive

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

Ole Troan <otroan@employees.org> Tue, 27 September 2022 20:57 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 E83BEC15C531 for <ipv6@ietfa.amsl.com>; Tue, 27 Sep 2022 13:57:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.514
X-Spam-Level:
X-Spam-Status: No, score=-3.514 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_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 CrmtrxVRnA3v for <ipv6@ietfa.amsl.com>; Tue, 27 Sep 2022 13:57:41 -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 1FC36C15DD59 for <ipv6@ietf.org>; Tue, 27 Sep 2022 13:57:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=employees.org; i=@employees.org; q=dns/txt; s=vesa202009; t=1664312261; x=1695848261; h=content-transfer-encoding:from:mime-version:subject:date: message-id:references:cc:in-reply-to:to; bh=womBIoyOBKP+aTbciBlsab7qBj1Cv1WE6onwj80V+7A=; b=YoHlbVNk6SKW0euAHGemlRK3fe5dx2wewC3p/1OjmwpjRq/clgSiXhy5 VF/cDj4pjl9Vd8IC0M23rMRlchu0xFKm2uCwP6zYS8AdwJL7gJjRE+BLt t2hieV/qKDjR3jo/JWphCD1HFyYquSYrsftft1BQwEQu6iYEGx5B+Eb6O x1TIxclPXkLn74U9tY7cqFxGbqaXa9+YDzZLtTFEk/xfXE6ffsDxnAIDx BTTu9rrvEZHcuuVLiV0mXfYcQnMGk3yad7UfsGEbZ0g1+ZyYZVzKP+8K6 cPlkqHmK6scNMemw2y6Ia4HqSvMDQQJHt5gHxunFB9emQXPV+qH4kcTLd g==;
Received: from clarinet.employees.org ([IPv6:2607:7c80:54:3::74]) by vesa01.kjsl.com with ESMTP; 27 Sep 2022 20:57:40 +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 1986F4E11A4F; Tue, 27 Sep 2022 20:57:40 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail-F798874B-7E11-4FE3-A5A4-E0D912F20CC3"
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 22:56:26 +0200
Message-Id: <AE339145-6752-4A84-B80B-B576BFCBFEFD@employees.org>
References: <CANMZLAZc-TbxaiQ0mbDjTOTf8Pvag1aH51ayXVorG3eTDNGt0w@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: <CANMZLAZc-TbxaiQ0mbDjTOTf8Pvag1aH51ayXVorG3eTDNGt0w@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/f5rbjA4EwmVCOG6YkrApps9S0Ms>
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:57:45 -0000


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