IETF Logo Mail Archive

Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis

Vasilenko Eduard <vasilenko.eduard@huawei.com> Wed, 27 March 2024 07:06 UTC

Return-Path: <vasilenko.eduard@huawei.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 07E16C14F71E for <ipv6@ietfa.amsl.com>; Wed, 27 Mar 2024 00:06:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable 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 rGI5KRLl5rA1 for <ipv6@ietfa.amsl.com>; Wed, 27 Mar 2024 00:06:54 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A506C14F71F for <ipv6@ietf.org>; Wed, 27 Mar 2024 00:06:54 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4V4Hfm2N45z6K8xk; Wed, 27 Mar 2024 15:02:24 +0800 (CST)
Received: from mscpeml100003.china.huawei.com (unknown [10.199.174.67]) by mail.maildlp.com (Postfix) with ESMTPS id 1D5A4140A90; Wed, 27 Mar 2024 15:06:51 +0800 (CST)
Received: from mscpeml500004.china.huawei.com (7.188.26.250) by mscpeml100003.china.huawei.com (10.199.174.67) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Wed, 27 Mar 2024 10:06:50 +0300
Received: from mscpeml500004.china.huawei.com ([7.188.26.250]) by mscpeml500004.china.huawei.com ([7.188.26.250]) with mapi id 15.02.1258.028; Wed, 27 Mar 2024 10:06:50 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
CC: 6man WG <ipv6@ietf.org>
Thread-Topic: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis
Thread-Index: AQHadVjmQOsKCr/KgkiNyHVa/TQBcbE3gnoA///l8wCAAAwVAIAFRF2AgAFHiYCABVVkAIAABgyAgACmnwCABSMpgIAAXzuAgAAUTYCAAVTJAIAAAasAgAARxoCAAD3xAA==
Date: Wed, 27 Mar 2024 07:06:50 +0000
Message-ID: <3335579abd2d477694c8ef7fea534ee3@huawei.com>
References: <CADmxuPF1AReQCSY13HjqXE+8Jofy_uoo1wmnzs8+whG7Tdc+UQ@mail.gmail.com> <836E3A12-FAAF-4C19-91A1-322203645AAA@employees.org> <CADmxuPEBXYeTPrJqfPEGaxmUM75iKQx6kfCcpHHjxyekZy0xuQ@mail.gmail.com> <492484.1711516392@dyas> <CAPt1N1=8B17ab6-54_L8u5KK1Px5AJ9j8VmTWec0Hp3Dg1OKKQ@mail.gmail.com> <CAKD1Yr2Yp_nVgkZ9g2Bgv6x9L29bh+RL889uOFw6WMmFHkxtNA@mail.gmail.com>
In-Reply-To: <CAKD1Yr2Yp_nVgkZ9g2Bgv6x9L29bh+RL889uOFw6WMmFHkxtNA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.199.56.41]
Content-Type: multipart/alternative; boundary="_000_3335579abd2d477694c8ef7fea534ee3huaweicom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/6rbxzBtwmgL6BaScHBVt8-2wNxQ>
Subject: Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 27 Mar 2024 07:06:59 -0000

  *   Hopefully DHCPv6 address registration and PD-to-the-device will help there
I believe it would not. Because somebody pushed huge address wastage into the solution – enterprises would not accept it.
Let’s hope you are right, not me. It would be good for the market.
Ed/
From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Lorenzo Colitti
Sent: Wednesday, March 27, 2024 09:23
To: Ted Lemon <mellon@fugue.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>; 6man WG <ipv6@ietf.org>
Subject: Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis

I don't think that's something we need to worry about, no. I haven't heard any such requests, and I don't think it would even work anyway without custom hardware. All CPEs do RFC 7084 and the basic model there is to use PD on the WAN to get a prefix for the LAN. And if the prefix isn't a /64 or shorter a lot of implementations won't work.

Enterprise is a different story; there are probably lots of enterprise network admins who want to assign a single /128 to a device using IA_NA. I'd guess the goal there is not price gouging but control and accountability. Hopefully DHCPv6 address registration and PD-to-the-device will help there.

On Wed, Mar 27, 2024 at 2:19 PM Ted Lemon <mellon@fugue.com<mailto:mellon@fugue.com>> wrote:
Are you aware of ISPs that are contemplating single-address-to-the-home or charge-per-device? Or is this just speculation based on remembered trauma?

Op wo 27 mrt 2024 om 01:13 schreef Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr%2Bietf@sandelman.ca>>

Naoki Matsuhira <matsuhira.ietf@gmail.com<mailto:matsuhira.ietf@gmail.com>> wrote:
    > I am not a native English speaker and this is the first time I have see the
    > word "unilaterally". If the meaning according to the English-Japanese
    > dictionary is correct, I feel that this is the reason why there are
    > opinions against adoption. How about that.

unilaterally in this context means that I can do something without someone
else's permission.

In particular, end-users have been able to "deploy" NAT44 on their
desktops/laptops in order to get their VMs or containers "online" without
permission from the (network) administrators.

At one point (1997), incumbent telco ISP thought that they would deploy PPPoE
to every single desktop in the home, charging more for each connection.
People said, "screw you" and put up a NAT44 on their own.  This became the
norm as home routers came out and people installed them ad-hoc, and then ISPs
deployed them as a matter of course.

We are risk the same price gouging behaviour in IPv6.
Yet, I support adoption of the document, although I would prefer to create a
new WG for it.


--
Michael Richardson <mcr+IETF@sandelman.ca<mailto:mcr%2BIETF@sandelman.ca>>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

v2.23.0 | Report a Bug | By Email