IETF Logo Mail Archive

Re: [v6ops] Fwd: New Version Notification for draft-linkova-v6ops-ipmaclimi-00.txt

Jen Linkova <furry13@gmail.com> Wed, 09 November 2022 01:10 UTC

Return-Path: <furry13@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4864C152596 for <v6ops@ietfa.amsl.com>; Tue, 8 Nov 2022 17:10:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.858
X-Spam-Level:
X-Spam-Status: No, score=-1.858 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 019w_6Y-4HUl for <v6ops@ietfa.amsl.com>; Tue, 8 Nov 2022 17:10:39 -0800 (PST)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 56297C14CE23 for <v6ops@ietf.org>; Tue, 8 Nov 2022 17:10:39 -0800 (PST)
Received: by mail-lf1-x135.google.com with SMTP id g7so23595891lfv.5 for <v6ops@ietf.org>; Tue, 08 Nov 2022 17:10:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=TkElHMvGpWlco28lQMv9duUzymTGwoxsexBoDDuWj3M=; b=ILq133HjdZ9IQrbQ9T1KNEmYIU2aqw+g7TqPIXSgxl2/qKfSTLoNXf8RxHJGOqqYWQ Myt7wtn/H8I6dGLgrHDjmU8cpw5JvhJsUIOMvKvmxhapWmadUrmcolnEvumbr2XIx8kh gmZWF/SjJorjkQfxrpUbU2Q+Rkxmd3lDSA5Es+8Y5iCLRJdl9igI1ixmhSAEnxGNrD4o ekRY6z1RrryvfaZZzZL8AIzldXAZueNNq/7YmCsdrpBcLa72baznTwK4TxT0xkYe0VN+ oYwDRAb/NGW2d1FndwRXa9b6IlejoFNbPw8tANHgIqti0flW5+pe+gegcBr1hgmkJju8 OqdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=TkElHMvGpWlco28lQMv9duUzymTGwoxsexBoDDuWj3M=; b=3IryTax951C0HZ+VGC/ciuo32HKpzNUeJ0kaHH+zBlGnpnvHiNjX/0w8rqJqdBKFub /E6j5c5DLvinMdlTavJN2+7h8SglOw4e/x2N1SCOW1rGX0gNvUq5KtEwS/TV4Oefmgef umP7IkU5GQ+1zFPBKSn8/ISZ8eVjyBX6iiZkbuvVwXhoJ5HJGqTMIF7lX3RU8Dw1iVvd pAxmXZCYD8eEFXCqdag9ALtiqdeCnj7CecotZAL6EQF6dImc/QSZBnc6y+QADP/9cx7Y sjKnku4C8QiTq6G+lqf4xHxAsm3jNkLpB9ot/cimWreXS9tdvD1iWzJSMrKsuEZM/Hpp 4+Rw==
X-Gm-Message-State: ACrzQf2KZ3k35KR5Om5UU4I2KJ1W0x9tMUNpViwsEhJ90ETf0NbDz5t2 CUB1b/v/7yzj6n8ucqXSiCRsRHsWfCND9gp1+0NnPV/q
X-Google-Smtp-Source: AMsMyM5QGEmtgs9KKWH78M4PIx92Tzo3FSq5anix2xUsVKyIsXdDt6QXwBcSQfAT43lnG26DYyYYPSGzAV1MYvdieX8=
X-Received: by 2002:a19:645e:0:b0:4a6:49d3:23b1 with SMTP id b30-20020a19645e000000b004a649d323b1mr22417034lfj.473.1667956237311; Tue, 08 Nov 2022 17:10:37 -0800 (PST)
MIME-Version: 1.0
References: <CAFU7BAQAo7p8MQOK9+CF3OEhOYp=vpUvX_4u9DadXaqQ7ada6w@mail.gmail.com> <9D3ABE32-2126-4FCA-BDDF-9E49EBFCB0FE@employees.org>
In-Reply-To: <9D3ABE32-2126-4FCA-BDDF-9E49EBFCB0FE@employees.org>
From: Jen Linkova <furry13@gmail.com>
Date: Wed, 09 Nov 2022 12:10:27 +1100
Message-ID: <CAFU7BAQmBRNtdT_qMb4ujWQgTmoMGwNnx+Viy51ULCTS7Uwrvg@mail.gmail.com>
To: Ole Troan <otroan@employees.org>
Cc: Nick Hilliard <nick@foobar.org>, V6 Ops List <v6ops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/A20cF13w8hn53T_3Iz-TqwINdbg>
Subject: Re: [v6ops] Fwd: New Version Notification for draft-linkova-v6ops-ipmaclimi-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Nov 2022 01:10:39 -0000

On Wed, Nov 9, 2022 at 6:10 AM Ole Troan <otroan@employees.org> wrote:
> > What I'm struggling to understand from this thread is: what's the
> > device supposed to do if it needs N addresses and the network only
> > agrees to provide N-1?
> > Shall the application fail? How is it better than the situation we have now?
> > Or do we want NAT66?
>
> I don’t think a host/application can assume that the network is willing to assign it an arbitrary number of addresses. Or any more than a single non-link-local address.
>
> With SLAAC we don’t have a mechanism for the host to request that it needs addresses, nor do we have a mechanism to signal from the network that it doesn’t get it.

OK, let's imagine we have a protocol X to do this.
Now my ChromeOS device requests X addresses for all namespaces.
The network is saying: "Sorry, can't do this, only X-1 addresses are available".
The only options I see are:
- a given application/namespace fails, causing a user-visible outage.
- NAT66.

-- 
SY, Jen Linkova aka Furry

v2.23.0 | Report a Bug | By Email