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 06:46 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 F1D49C152583 for <v6ops@ietfa.amsl.com>; Mon, 19 Dec 2022 22:46:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 TUMUj5jva4r0 for <v6ops@ietfa.amsl.com>; Mon, 19 Dec 2022 22:46:19 -0800 (PST)
Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) (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 9BE77C152580 for <v6ops@ietf.org>; Mon, 19 Dec 2022 22:46:19 -0800 (PST)
Received: by mail-vk1-xa31.google.com with SMTP id g137so5340672vke.10 for <v6ops@ietf.org>; Mon, 19 Dec 2022 22:46:19 -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=gdVoPY/6XFikCnLK4px1gzOHO01ghG+tkJ4R2xoaEOg=; b=Io83tLOgo0UWmGnFxZXfqToyUzBwGdu/rpv3FzrxGmRzuygi6MPp/qjEX5Nng+MuHS YwE3//SeDBNuij5BLOf5F6RUlm7Qf3xrt3jegpN5/elE3es4HpxlSRRg/vFkFVOshHRH 2wBoMWhUDvorWMNhdRFjUUyQ5+Nsh7/PMB3JXOd9fq2GFYzL6G8jpz2sJ7NaNf6qX1My +PvoCjFYgh1zBu8NYhszQgJxgZBtOO3JWypAcUSXG9ouH/l31z7K3fIQmB9Oi26dqV2v ALw8gvVMY0lghISc0CfFtgwZkG2kq9iguKTb4+ZJc/5N3yrU+tCQOWp7ocKDHTR5mwOF EekA==
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=gdVoPY/6XFikCnLK4px1gzOHO01ghG+tkJ4R2xoaEOg=; b=f6vo0tCY/3qJdoK7YGmHulgVLBSXiP/IcTNGlrIbSCNRd53MrprO9Xe0CcV7Mgx9E4 fGDX79VdruZcCs2bkanbZHshyVp2o4+jHLpzdDEX2iTxWZE0rzOVpdSynLNvZVhW/1CR sX2buy6MIPPA8eZRqls7nAJ8e/oLxzYFy/SLjd5mpUOyIL8j3OtV4G0SomTks37Eh6UF PKP6Aq5rNoItl9xDJFupX4JeLnPjm60JeoVf5eyk+HGGssH3g/2NXZ3tdnS8MKzC+GRz 2N0dN8KK8iAEtG/c7EqOFTOcVuf4Td7zagWQpo8igK8ZMO5vgDCk4Xb/VZfZVdQM92XH Wnig==
X-Gm-Message-State: ANoB5pn85P3FJBaOk72pCLJuD7i2mhJ/tEJ1riQroAQySzbymmodxsQ3 eHr6mmyAW6z+6yHjWe8MXXMpBlhJbaUXLipynmSjcQ==
X-Google-Smtp-Source: AA0mqf4MSns0AgkJuZJ5NhcLAvPuWY1XZSPtmZ2w76q0SxocOjKx5x2WUVGAApEYlTpm0xKHp6MtgKApt6tGPEyw7Iw=
X-Received: by 2002:a1f:c1d8:0:b0:3bd:77be:a48a with SMTP id r207-20020a1fc1d8000000b003bd77bea48amr17317629vkf.15.1671518778247; Mon, 19 Dec 2022 22:46:18 -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>
In-Reply-To: <63C4488F-AF94-41EB-A892-EFAB788CF0A3@gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Tue, 20 Dec 2022 15:46:05 +0900
Message-ID: <CAKD1Yr0yGWBtzsHW4Kx+TpCAvN1UK5X4bV=LMOkRQ==-T4=80w@mail.gmail.com>
To: Fred Baker <fredbaker.ietf@gmail.com>
Cc: Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>, Jen Linkova <furry13@gmail.com>, V6 Ops List <v6ops@ietf.org>, "draft-collink-v6ops-ent64pd@ietf.org" <draft-collink-v6ops-ent64pd@ietf.org>, "xiaom@google.com" <xiaom@google.com>
Content-Type: multipart/alternative; boundary="00000000000003c6ad05f03ccb88"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/SYxs1mHSfm8oVx3DWm2XdVi2EtM>
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 06:46:20 -0000

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.

v2.23.0 | Report a Bug | By Email