IETF Logo Mail Archive

Re: [v6ops] New Version Notification for draft-collink-v6ops-ent64pd-01.txt

Lorenzo Colitti <lorenzo@google.com> Tue, 20 December 2022 07:04 UTC

Return-Path: <lorenzo@google.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 8B125C152589 for <v6ops@ietfa.amsl.com>; Mon, 19 Dec 2022 23:04:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.597
X-Spam-Level:
X-Spam-Status: No, score=-17.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 DVMhbZvSZbW8 for <v6ops@ietfa.amsl.com>; Mon, 19 Dec 2022 23:04:16 -0800 (PST)
Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 D7230C14CE29 for <v6ops@ietf.org>; Mon, 19 Dec 2022 23:04:16 -0800 (PST)
Received: by mail-vs1-xe34.google.com with SMTP id d185so11025112vsd.0 for <v6ops@ietf.org>; Mon, 19 Dec 2022 23:04:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=IuPwWxkryWEaDAazVZO/2mCUYxb9oZLJOIUI5VFRR3Q=; b=VZ5HMBz20nNqflN7fsUNf37Fnr7/cuzv3Nr9faSEvnJcZRIe53tRoW6KuTo/slQpoj j5TvKx0TuY1zbZrXRT5RCTUzZkOwktSXFb4v4wkaCo9RNtqzA94OmdiACOew20I3RKJF X7kxYYXbaaVmgynp0pEkD8cGQZJRDlAONoNXyVA9CvTj/sTSOpDTVNr1KHPtpi4N5jq+ janjTSEBmmpflGCqsdU9CIOEdWNB5KKg9BWDH1gLHoZ3A5Xc6/Yz/CkdYpJuth8TRcww 5P3jKVzczXBSdwH9TipsO2IcDRc3QswmpmojTTnN0sFknWwX6APDr1FVWSQ38O0n3w9s tj6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=IuPwWxkryWEaDAazVZO/2mCUYxb9oZLJOIUI5VFRR3Q=; b=u+DDu2QJ/AYu6i3HjJZ5pxZe9zeoCeVZS5MW7itOsAhBMiIcOUufjnphZaJKqAS4UZ 1tcPWGz5sfpocT/e+NqEYUnLlM07WEwZmnSiKJcxTYSxWUr+FDMTX92Fz8CWn3OaHRfB Sxja4MFr2xDHQQ5xnLb0tcwFHeEA28K1yVhe5kXi3YYMftsuvgDYAZi1RhUk4nm3j0MI NtgnCLsyb9u5+vHbMRPNXzzGeFFbLEyMTU9ZHbUjA4x1VEE8zF03O+nc1kT5GcQ136sZ RZaIbYR17H92b6LYW2P/T42Q5gTl6w/dBap2nYY0tLHtMD8A01F2Cu8zp2AR4ayG0Quf WpSQ==
X-Gm-Message-State: ANoB5pleYDstvfFE47m3UGHn5LiitS1P5Hf/NA71QexJ6A4b4ZLKAVU5 2FlBBr2s2YvXHSNtUNUZ+88xH/bAh7VOINhCuGeS0w==
X-Google-Smtp-Source: AA0mqf4rS+UpA12gtJ1enkVGnh3isCnVjCh0f+BWE5Ua0h0txnj7bsZM3KKUwwgKLJZ9S4szFafnNXK0ErT6CpnhVWo=
X-Received: by 2002:a67:e19a:0:b0:3b5:1126:2b62 with SMTP id e26-20020a67e19a000000b003b511262b62mr3530826vsl.51.1671519855793; Mon, 19 Dec 2022 23:04:15 -0800 (PST)
MIME-Version: 1.0
References: <167107554671.48477.568330207202509840@ietfa.amsl.com> <CAFU7BATp=gEB3S8AzhCYDMN3fzLQrYY9pzcWJ=LQnrjC9bRKEA@mail.gmail.com> <a2b83708c99344b2afb5e65c899b2f76@huawei.com> <63C4488F-AF94-41EB-A892-EFAB788CF0A3@gmail.com> <CAKD1Yr0yGWBtzsHW4Kx+TpCAvN1UK5X4bV=LMOkRQ==-T4=80w@mail.gmail.com> <CAO42Z2xAdcEQ1oX05VUT8=ZH1SHujQJtMqmngOOwt6K+0yM_Ow@mail.gmail.com>
In-Reply-To: <CAO42Z2xAdcEQ1oX05VUT8=ZH1SHujQJtMqmngOOwt6K+0yM_Ow@mail.gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Tue, 20 Dec 2022 16:04:03 +0900
Message-ID: <CAKD1Yr3U8_hWdeCQRiXBiduh+ZySwN8QbDFO8Ot-cBJ89h0ekg@mail.gmail.com>
To: Mark Smith <markzzzsmith@gmail.com>
Cc: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>, Fred Baker <fredbaker.ietf@gmail.com>, draft-collink-v6ops-ent64pd@ietf.org, Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>, xiaom@google.com, V6 Ops List <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003dbd8505f03d0b57"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/0PHAw7PTsYhqhDMFl50Pv2b8Tc8>
Subject: Re: [v6ops] New Version Notification for draft-collink-v6ops-ent64pd-01.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: Tue, 20 Dec 2022 07:04:17 -0000

I think it makes more sense in the PIO is that SLAAC occurs on a per-PIO
basis. The same link may have multiple PIOs with different uses (e.g., a
global prefix and a ULA announced by a stub network
<https://datatracker.ietf.org/doc/draft-lemon-stub-networks/> that doesn't
have a DHCPv6 PD server). Putting the flag in the PIO allows the network to
specify this on a per-prefix basis, and say, for example, that the client
should get a global prefix but use SLAAC for the ULA.

On Tue, Dec 20, 2022 at 3:51 PM Mark Smith <markzzzsmith@gmail.com> wrote:

>
>
> On Tue, 20 Dec 2022, 17:46 Lorenzo Colitti, <lorenzo=
> 40google.com@dmarc.ietf.org> wrote:
>
>> On Mon, Dec 19, 2022 at 1:18 PM Fred Baker <fredbaker.ietf@gmail.com>
>> wrote:
>>
>>> > 1.    What is the point to keep SLAAC if DHCP infrastructure is
>>> mandatory?
>>>
>>> What I might suggest is to make SLAAC normal (as s the current case,
>>> e.g., retaining backward compatibility) and provide a way to tell hosts
>>> that they should request a prefix via DHCP-PD.
>>
>>
>> That is in fact the intent here. Section 8 mentions that good coexistence
>> with SLAAC requires an extra flag in the PIO. The flag would effectively
>> mean, "this network supports SLAAC, but if you want more address space, you
>> can request a prefix". This ensures that networks without a lot of address
>> space (e.g., home networks, SMEs etc.) can use SLAAC without running out of
>> IPv6 prefixes.
>>
>
>
> I was thinking an additional flag in RAs, in the set of the M and O flags
> ('P' for host Prefix?). That seems a bit more intuitive to me than a PIO
> flag.
>
> Regards,
> Mark.
>
>
>
> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>

v2.23.0 | Report a Bug | By Email