[IPv6] PvD (RFC 8801) is not relevant to MHMP

Vasilenko Eduard <vasilenko.eduard@huawei.com> Thu, 01 December 2022 17:34 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 82BD5C14CF05 for <ipv6@ietfa.amsl.com>; Thu, 1 Dec 2022 09:34:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Level:
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 fahAJgqjsQSc for <ipv6@ietfa.amsl.com>; Thu, 1 Dec 2022 09:34:41 -0800 (PST)
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 CFEEBC14F73D for <ipv6@ietf.org>; Thu, 1 Dec 2022 09:34:40 -0800 (PST)
Received: from fraeml735-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4NNNR80jh9z6HJFf for <ipv6@ietf.org>; Fri, 2 Dec 2022 01:31:32 +0800 (CST)
Received: from mscpeml100002.china.huawei.com (7.188.26.75) by fraeml735-chm.china.huawei.com (10.206.15.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Thu, 1 Dec 2022 18:34:38 +0100
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml100002.china.huawei.com (7.188.26.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Thu, 1 Dec 2022 20:34:37 +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, 1 Dec 2022 20:34:37 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: "ipv6@ietf.org" <ipv6@ietf.org>
Thread-Topic: PvD (RFC 8801) is not relevant to MHMP
Thread-Index: AdkFqg3UDW4ltMTnSF2gmDjoRTrU/A==
Date: Thu, 01 Dec 2022 17:34:37 +0000
Message-ID: <8e49314ba8304b54be88fc365987a97c@huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.126.170.114]
Content-Type: multipart/related; boundary="_004_8e49314ba8304b54be88fc365987a97chuaweicom_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ggJ6kxYbW7dWgcJ5RhvzTw7vpeY>
Subject: [IPv6] PvD (RFC 8801) is not relevant to MHMP
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, 01 Dec 2022 17:34:46 -0000

Hi all,
Some people insist that PvD (RFC 8<https://www.rfc-editor.org/rfc/rfc7084>801) is the solution for MHMP.

PvD permits to:
- split one physical router on many virtual (implicitly or explicitly).
- inform the host of relationships between DNS, PIOs (and other parameters) to show what is a consistent set of information from the particular Carrier.
That's it.
"Many routers" with PvD would still be "even more routers".

If the application would use getaddrinfo(),
Then the host would still try to choose the next-hop initially (RFC6724) in a random manner (ND section 6.3.6).
If the wrong physical or virtual router is chosen then rule 5.5 RFC 6724 would restrict PIOs applicably (the wrong PIO would be chosen too).
As a result, the packet would try to access the "walled garden" from the wrong address pace, it would be dropped.

I do not see how PvD is helping MHMP at all.
Because multiplying routers number on the link is not a solution when the host is not capable to choose which one to use.
The host would still have chances to choose the wrong one (initially as the next hop, later as a PIO).
Moreover, in the situation in the picture below (2 virtual routers out of one physical), PvD would create an MHMP problem (that was absent before PvD).
Because PvD would give the host a chance to choose the wrong virtual router with the wrong PIO.
[cid:image001.jpg@01D905C4.51E65A00]
Eduard