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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 21 September 2021 21:13 UTC

Return-Path: <brian.e.carpenter@gmail.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 18C6B3A1451 for <ipv6@ietfa.amsl.com>; Tue, 21 Sep 2021 14:13:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 mGL_6AeZC5ca for <ipv6@ietfa.amsl.com>; Tue, 21 Sep 2021 14:13:32 -0700 (PDT)
Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C65D3A1452 for <ipv6@ietf.org>; Tue, 21 Sep 2021 14:13:32 -0700 (PDT)
Received: by mail-pf1-x431.google.com with SMTP id y8so753662pfa.7 for <ipv6@ietf.org>; Tue, 21 Sep 2021 14:13:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=k0JB9b+qLGAQG6jDosTKYiV9lxGrg7s129czqu1mGv8=; b=kX2fVxe89Mrh4XwCKnxzbGILJ9I/s7TYNfxU91fB9vKEEtth6WQLPzcu/YGpdGYYms tFZAmGUjKF7u0HHLzd3kuzyEN9vebl6iuuY0Munx+HOyv0CYsT2lM74AdRf+yB9XrBtd E2GNnY3G0iVMvNNX6rnsyrIRR1XRf9Sz9xFuamkwK3Fyj6T7UmYb7YqFIvECWTlVIEce 0uy6mbk9JuzZpET7Nv7RxRmn21Z4xgx8iYbYnL/6PbhGNcCO9TXqh4r2OIHLw4BEDOGZ CoaprJnR0vJyWvytm8wX7d9Up3Fgu8ffK2PZy+o94o1p6o7ONXhRmjCM2WtkAVSlpxeA 7bYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=k0JB9b+qLGAQG6jDosTKYiV9lxGrg7s129czqu1mGv8=; b=EmDD1HWmcnFinyBX4jV84Ripq5L55x7x7BpFqZMOZGvYH5U4z7slMVgkUpBmLQ9xX4 RsId8nxr6m69vHV1sCE3dh+qqKKHzk7D6871heSp0VJLtAMLdKzKDQ5DWnV10ynC2BGS CS8kZfMDSFgN+Jwsjw64BKFiIBYdPyVTzMP9xbkKDcb7guh1hoik/6HSlc+edPWNIwYA qQcmLnxX4JUPHyf3y2Wmcq0k7UP5XIWyCRLyhBbkLTj8zg0AvShIHWcsRAHQiddBB7DB AYm8EsrtrIoudI1FaX3UWGcAjjBHulI2okSHGoRjTgjqaGqDOv7uFvzHVA2yKlKWLrwo aFnA==
X-Gm-Message-State: AOAM532rX3YLb/9aNZBGuOQsp1a3xrpo2UA417McQYRYk8xvkk3qJk+e bpvgn/4vHCQUhfaISX78e45OrwJEoMu9qw==
X-Google-Smtp-Source: ABdhPJxt++FoMBlZQevPSfXBwBAsgMMu/STH3nH+tz3lbhRaDjcsEsPl9ow3VAzNGnQx4ajX7/8qGA==
X-Received: by 2002:a05:6a00:a10:b0:412:448c:89c7 with SMTP id p16-20020a056a000a1000b00412448c89c7mr32036670pfh.83.1632258811407; Tue, 21 Sep 2021 14:13:31 -0700 (PDT)
Received: from ?IPv6:2406:e003:11aa:d701:80b2:5c79:2266:e431? ([2406:e003:11aa:d701:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id w67sm89638pfb.99.2021.09.21.14.13.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Sep 2021 14:13:30 -0700 (PDT)
Subject: Re: Adoption Call for <draft-troan-6man-universal-ra-option>
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>, Fernando Gont <fernando.gont=40edgeuno.com@dmarc.ietf.org>, Lorenzo Colitti <lorenzo@google.com>
Cc: IPv6 List <ipv6@ietf.org>
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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <584325b9-b978-2c0a-c782-12d470809143@gmail.com>
Date: Wed, 22 Sep 2021 09:13:26 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <17228f7ef1ad4a6f85654f3d1fdea27e@huawei.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/EG4WDBna2hIHZxtFpj3cfitMiqA>
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: Tue, 21 Sep 2021 21:13:37 -0000

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