IETF Logo Mail Archive

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

Fernando Gont <fgont@si6networks.com> Thu, 12 January 2023 10:38 UTC

Return-Path: <fgont@si6networks.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 D62F3C1907D5 for <v6ops@ietfa.amsl.com>; Thu, 12 Jan 2023 02:38:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 XiTX9-WyhQXe for <v6ops@ietfa.amsl.com>; Thu, 12 Jan 2023 02:38:48 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 B5072C153CBF for <v6ops@ietf.org>; Thu, 12 Jan 2023 02:38:48 -0800 (PST)
Received: from [192.168.100.19] (unknown [190.183.21.160]) (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 fgont.go6lab.si (Postfix) with ESMTPSA id 1E520282D88; Fri, 23 Dec 2022 13:52:36 -0300 (-03)
Message-ID: <f88b5ae1-73d4-3c64-e99d-b85b0da18b45@si6networks.com>
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2
Content-Language: en-US
To: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>, Martin Huněk <martin.hunek@tul.cz>
Cc: V6 Ops List <v6ops@ietf.org>
References: <167107554671.48477.568330207202509840@ietfa.amsl.com> <38341414.10thIPus4b@asclepius.adm.tul.cz> <CAFU7BAQYc=BP7=A+KzH2TbUu3iw1ue3_yAfxgxV6q4CKGP-J8Q@mail.gmail.com> <2788479.88bMQJbFj6@asclepius.adm.tul.cz> <CAKD1Yr3vDCwnMA_Hpq0w2OQmX+uCEtMpfRMssCdSSrsLvMnwKQ@mail.gmail.com>
From: Fernando Gont <fgont@si6networks.com>
In-Reply-To: <CAKD1Yr3vDCwnMA_Hpq0w2OQmX+uCEtMpfRMssCdSSrsLvMnwKQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/agE94fHY_ktrvt39VXuUT4wH-Ms>
Subject: Re: [v6ops] Fwd: 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>
Date: Thu, 12 Jan 2023 10:38:51 -0000
X-Original-Date: Fri, 23 Dec 2022 13:48:32 -0300
X-List-Received-Date: Thu, 12 Jan 2023 10:38:51 -0000

On 20/12/22 21:50, Lorenzo Colitti wrote:
> On Wed, Dec 21, 2022 at 8:44 AM Martin Huněk <martin.hunek@tul.cz 
> <mailto:martin.hunek@tul.cz>> wrote:
> 
>     Isn't this situation comparable with connecting a physical switch to
>     an Ethernet port configured and limited for a single device? I mean,
>     this is known even in IPv4, isn't it? At our university, if someone
>     wants to connect a switch, they have to ask first to have that
>     limitation lifted. Same in IPv6, if you need to have 10 global
>     unicast addresses per device, it is not standard behavior, so you
>     should ask first. As I understand, it is a protection against a
>     malicious device that would ask for an infinite number of addresses
>     or obsoleted privacy extensions that had a similar property.
> 
> 
> It's very much not the same, because in IPv4 anyone who can connect to 
> the network and get an IPv4 address can provide IPv4 connectivity to 
> unlimited devices via NAT.
> 
> IMO that is actually one of the best things about this draft: it 
> provides a way to do the same in IPv6, while giving those unlimited 
> devices true end-to-end-connectivity,

While DHCPv6-PD is valuable (if we're going through the hassle of 
deploying v6, we better use the addresses, right?), there are a few 
things to consider:

  * DHCPv6 support in clients -- for this option to be feasible, maybe
    DHCPv6-PD support should be made mandatory in clients. (OTOH..
    really?)

  * Giving the impact of this /64 per host discussion, and its pressure
    on the address space, there's probably a longer range architectural
    decision that needs to be had -- including in RIR circles.

  * Also note that while there might be enough /64 prefixes for the local
    clients (e.g. if the (lucky) CPE got a /48), the CPE itself might be
    unable to lease that many addresses (if at all possible).


Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494

v2.23.0 | Report a Bug | By Email