RE: RFC6724-bis?

Vasilenko Eduard <vasilenko.eduard@huawei.com> Thu, 22 September 2022 17:22 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 DC308C14F745 for <ipv6@ietfa.amsl.com>; Thu, 22 Sep 2022 10:22:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 KhpnQSxrLebd for <ipv6@ietfa.amsl.com>; Thu, 22 Sep 2022 10:22:55 -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 90A63C14F718 for <ipv6@ietf.org>; Thu, 22 Sep 2022 10:22:55 -0700 (PDT)
Received: from fraeml739-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4MYMXB4sBsz67x9N; Fri, 23 Sep 2022 01:21:46 +0800 (CST)
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by fraeml739-chm.china.huawei.com (10.206.15.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Thu, 22 Sep 2022 19:22:52 +0200
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml500001.china.huawei.com (7.188.26.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Thu, 22 Sep 2022 20:22:51 +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; Thu, 22 Sep 2022 20:22:51 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, Mark Smith <markzzzsmith@gmail.com>, Ted Lemon <mellon@fugue.com>, 6man WG <ipv6@ietf.org>
Subject: RE: RFC6724-bis?
Thread-Topic: RFC6724-bis?
Thread-Index: AQHYzQsTYjAQjrj/LUqdQU83Wias3q3pVHuAgAAGaoCAAAE6AIAABQoAgAFZtQCAAPNY2YAABrlg
Date: Thu, 22 Sep 2022 17:22:51 +0000
Message-ID: <04f9b6801cd849c2b8aaa861ce34e3d1@huawei.com>
References: <66892DC8-6DA4-4DC8-85B0-E1E1647CD9F7@gmail.com> <CAM5+tA9kttCKrZaoB7UzNdE6TU1qGNMaxDmWvFtRvpB4A8+WHA@mail.gmail.com> <8FE71499-D155-4853-A964-6617F6EA2069@gmail.com> <CAM5+tA9QuYxVs+NXBD3dAYr_Y=95bWt63WjmEMDOfegL0Z4otA@mail.gmail.com> <CAM5+tA_hg2sXXsYw6Tcx-ytRAMkKQcFw8a3N7SfEXwbuPm0LMw@mail.gmail.com> <00ea3b70-ba8e-b6ef-e1ce-fdd56828f506@gmail.com> <CAPt1N1=_9Rwj-HnUZKWfatARbHWptArmSAV-qdi8MKyoBf9R0A@mail.gmail.com> <CAO42Z2xZ_-mDh66A9DK+3ieEqGMqW0Pt+mZzVOmzz4cDRUTEXA@mail.gmail.com> <371784.1663865687@dooku>
In-Reply-To: <371784.1663865687@dooku>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.150.119]
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/239e4a8ZHoudJE7_9JhN7IwtcQQ>
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: Thu, 22 Sep 2022 17:22:56 -0000

IMHO: the more structured discussion would be If separate the discussion about:
- ULA prioritization under the assumption that all routers have exactly the same PIOs
- and how to deal with MHMP where routers announce different PIOs.
It would not make the MHMP case more complicated
But greatly simplify the ULA case.
Eduard
-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Michael Richardson
Sent: Thursday, September 22, 2022 7:55 PM
To: Mark Smith <markzzzsmith@gmail.com>; Ted Lemon <mellon@fugue.com>; 6man WG <ipv6@ietf.org>
Subject: Re: RFC6724-bis?


I think that Mark is really asking why we aren't doing happy eyeballs *in the kernel*, (or at least, below the typical application interface).  Of course, that requires new APIs that take a struct addrinfo, rather than a sockaddr.

The other thing that I wonder is why RAs announce a ::/0 route, when I rather wonder if the router ought to know better about it's connectivity, should really be advertising a route to 2000::/3.

I don't think this really solves the ULA vs IPv4 etc. issue, but I keep thinking that it would make some of the dicussion clearer, but it would also result in no route to host more clearly for all the other empty spaces.


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