RE: Adoption Call for <draft-troan-6man-universal-ra-option>

Vasilenko Eduard <vasilenko.eduard@huawei.com> Wed, 22 September 2021 13:42 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 B2F943A216C for <ipv6@ietfa.amsl.com>; Wed, 22 Sep 2021 06:42:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.886
X-Spam-Level:
X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkMCce3cLEks for <ipv6@ietfa.amsl.com>; Wed, 22 Sep 2021 06:42:07 -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 153F53A2168 for <ipv6@ietf.org>; Wed, 22 Sep 2021 06:42:07 -0700 (PDT)
Received: from fraeml744-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HDzsx2jy6z6FGY9; Wed, 22 Sep 2021 21:39:17 +0800 (CST)
Received: from mscpeml100002.china.huawei.com (7.188.26.75) by fraeml744-chm.china.huawei.com (10.206.15.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Wed, 22 Sep 2021 15:42:03 +0200
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.2308.8; Wed, 22 Sep 2021 16:42:02 +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.2308.008; Wed, 22 Sep 2021 16:42:02 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
CC: IPv6 List <ipv6@ietf.org>
Subject: RE: Adoption Call for <draft-troan-6man-universal-ra-option>
Thread-Topic: Adoption Call for <draft-troan-6man-universal-ra-option>
Thread-Index: AQHXmMmhx5HKsbJa9UOIybdgsBIa+6uDHOqAgAAJHwCAAumHAIAgF3UAgAFgcACABmXsgIAAWUGAgACwiACAAArFAIABNvfw
Date: Wed, 22 Sep 2021 13:42:02 +0000
Message-ID: <affc62b7999f409f904f9f2e8fd81006@huawei.com>
References: <FB7CE846-627F-43CF-A54C-35B0EE6D5A2D@gmail.com> <c7a49df3-59a1-ac24-3d6a-8d71896733a1@foobar.org> <84347b3f-8462-4dc6-580d-544b1bf8aaad@gmail.com> <CAKD1Yr0NapC=Hw9WcjZcKi5O0FE0pM413wqSMALS0310Ps3R8g@mail.gmail.com> <cd2b98a8-4f3e-3d1e-4b6b-0d4c7e2745e9@gmail.com> <CAKD1Yr0cYC=g4WhmYvEmn4W9npFu-xjWKf8hd55fwbjAFFo_yA@mail.gmail.com> <109a3287-38da-1ab2-453a-74422a8f75a3@gmail.com> <a0673b6f-9d46-0e6b-976f-bab44f372b9d@edgeuno.com> <17228f7ef1ad4a6f85654f3d1fdea27e@huawei.com> <584325b9-b978-2c0a-c782-12d470809143@gmail.com> <CABNhwV0qpS3X5dciX-2hM5wnZzbjMoPYZsmTDo5xRWtauZceLQ@mail.gmail.com>
In-Reply-To: <CABNhwV0qpS3X5dciX-2hM5wnZzbjMoPYZsmTDo5xRWtauZceLQ@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.192.53]
Content-Type: multipart/alternative; boundary="_000_affc62b7999f409f904f9f2e8fd81006huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ZKIBoO5g4XSUZ4AcoRa1QLBed3k>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 22 Sep 2021 13:42:13 -0000

Hi Gyan,
Just try to find a vendor that would be capable to support redundancy for SOHO. "the dentist's office scenario"
i.e. 2 routers connected to different Carriers.
MHMP (multi-home multi-prefix environment) still does not work. The traffic drop probability would be 50%.
It is partially because of SLAAC – need to support the self-appointment of IPv6 addresses.
Yes, I know that there are RFC 8028 general recommendations. Is any implementation exist?
It is the year 2021 (+25 years). We are discussing “network programmability”, “application-awareness”, and so on.
But basic redundancy is not possible…
At the time when IPv6 has been developed – it was popular to talk about the KISS design principle. It is broken in IPv6.
Flexibility always comes with complexity, then with low security. KISS.
My conclusion: IPv6 needs radical simplification. SLAAC is the 1st candidate because distributed intelligence is always complex.
Eduard
From: Gyan Mishra [mailto:hayabusagsm@gmail.com]
Sent: Wednesday, September 22, 2021 12:52 AM
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Fernando Gont <fernando.gont=40edgeuno.com@dmarc.ietf.org>; IPv6 List <ipv6@ietf.org>; Lorenzo Colitti <lorenzo@google.com>; Vasilenko Eduard <vasilenko.eduard@huawei.com>
Subject: Re: Adoption Call for <draft-troan-6man-universal-ra-option>


Quick comment.

SLAAC and DHCPv6 play well together in my experience, however I think the playing well maybe vendor implementation specific.

The M/O bits control stateful nature and various bit combinations, however for simplicity as long as M=1 a managed address is sent by DHCP relay & reply back to the hosts on the subnet.

As for SLAAC, the router prefix and Default route is sent via the RA, and I believe most vendors have that knob enabled by default.

So hosts get both a stateful I believe Windows flags as “public” address as well as a SLAAC address.

Windows dos prompt  command
“netsh interface ipv6 show address”

“netsh interface ipv6 show interface <index>“ shows the M/O bits received and cached by the host.

There is a vendor specific knob “ipv6 be default no-advertise” which disabled SLAAC so the host only gets DHCPv6 address.

Without the knob disabled the host gets both addresses and then used Default address selection to pick which to use.

As long as the subnet is a /64 as SLACA has the /64 RFC 4862 requirement then all 3 addressing methods static, DHCPv6 and SLAAC can live together on the same subnet.

Kind Regards

Gyan

On Tue, Sep 21, 2021 at 5:13 PM Brian E Carpenter <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>> wrote:
On 21-Sep-21 19:51, Vasilenko Eduard wrote:
> Hi Fernando,
> The idea "standardize any remaining" looks good but SLAAC and DHCP are so different by architecture that it would not be possible.
> Example: DHCP is the choice for all types of businesses because of traceability (billing, troubleshooting, forensic) but SLAAC is silent in principle.
> Hence, SLAAC would be stuck in use cases where it is enforced by one company. If not this support SLAAC would be dead by now.

Absolutely not. It isn't "enforced by one company". It does exactly what it was designed
to do, what we called "the dentist's office scenario" in the early days of IPng design, actually modelled mainly on Appletalk. You can hook a few IPv6 boxes together on a wire and they will start talking to each other using SLAAC and link-local addresses. Add a router with a prefix and they will start talking to the world using SLAAC and RA. DHCPv6 is completely unnecessary until the network reaches a certain level of complexity.

The problem area isn't the simultaneous existence of SLAAC/RA and DHCPv6. It's that they don't play well together. Maybe we should restate the problem as "how to make SLAAC/RA play together better". And task a design team with that problem.

On 22-Sep-21 07:04, Vasilenko Eduard wrote:

> Sorry, I still do not understand why the default router should be on DHCP.
> It is just 1 bit: "I am the router on this link". Almost always activated bit. No choice, no parameters. Easy to demarcate between different teams.

Well indeed, the value comes when there are several routers (hence RFC8028). If you would like an equivalent of that functionality in DHCPv6, please specify it.

(And BTW it is, to my understanding, implemented on the host side. If operators ask for it, no doubt it will appear on the router side.)

>
> What is really a challenge: the prefix announced through the particular interface ("PIO"). The router should know where is this subnet.
> If prefix would be delivered through DHCP then the router should snoop and appoint the appropriate prefix to the interface.
> Probably you mean this challenge under the name "default router".

One thing about RFC8028 is that it shows that the phrase "default router" is insufficient, because the host needs to know the best router for a given prefix, not a general default.

> I propose snooping on the router side to learn prefixes.
> By the way, IPv4 world does not have any automation here (like snooping) - they coordinate it manually between teams.
> The situation is more challenging for IPv6 - many prefixes need to be coordinated. Hence, more importance for automation of this process.

Indeed. I think that is why we had the MIF WG. Any sign of PVDs in the real world?

    Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>

M 301 502-1347