Re: [**EXTERNAL**] Re: the race to the bottom problem

"Joel M. Halpern" <jmh@joelhalpern.com> Sun, 08 November 2020 19:57 UTC

Return-Path: <jmh@joelhalpern.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 B55AE3A09F0 for <ipv6@ietfa.amsl.com>; Sun, 8 Nov 2020 11:57:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qirQ-FwwUWvM for <ipv6@ietfa.amsl.com>; Sun, 8 Nov 2020 11:57:13 -0800 (PST)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E473A09D8 for <ipv6@ietf.org>; Sun, 8 Nov 2020 11:57:13 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4CTlJm6kVfz1nsSs; Sun, 8 Nov 2020 11:57:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1604865432; bh=3qNMyjtf6GSUw5uXSgpX47Vsp297N1CDWpS74KqdNew=; h=Subject:To:References:From:Date:In-Reply-To:From; b=KZQ9sV41qOPwPY3hILSWBu0sJ1ZmXZJy9iQ5PZitGa6B2/3pQxEaakPRP3t+KX5WN GBj82vsulLjQ/FT8pgc/n0+cqlysVYnvMH23EO5tMDnmxCBm3FpqsQexWbRfnmfyXf NqOI9kZn9GAvwQXr99thpLHPib68hI9QRMYz3pRg=
X-Quarantine-ID: <p1hJeHtX3snj>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4CTlJl4qDSz1nsSn; Sun, 8 Nov 2020 11:57:11 -0800 (PST)
Subject: Re: [**EXTERNAL**] Re: the race to the bottom problem
To: JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>, 6man WG <ipv6@ietf.org>
References: <160409741426.1448.16934303750885888002@ietfa.amsl.com> <CABNhwV1zoZpZNjb54rEys4+49H3vpebZW2g9JbO1_58eR+WnQg@mail.gmail.com> <CABNhwV3L7kz=cWu8s3X=djVf4MCwewzbEgx09TWaKzCULCjYUQ@mail.gmail.com> <9A9CE8E7-3552-4FD8-A50E-1BDCA2CB813F@employees.org> <CABNhwV0LxM7EuKo2wNtVacjewsVqdhrmSiVBmB_EL-mqJYdU3A@mail.gmail.com> <CD9F9F09-2CBC-4A72-99C0-4A9A470357ED@employees.org> <9e787ed0-a221-e413-e030-ac2553dffc8e@gmail.com> <a21c9447-730b-e2c0-81f6-46deda57f507@gmail.com> <f4635fa9-45ca-f7ec-40a2-41764e1ca74f@si6networks.com> <905bcc26-a223-53d0-6675-c35579b9a8be@gmail.com> <AAE75F7F-F8DF-4B7F-9C50-3D6C91544997@ciena.com> <2b59b2de-3597-8d35-374d-75e9b10d4d83@gmail.com> <CAO42Z2zUvDE2ZSCnZa_525Hj7OthhEoDGZcd0D9xxZVW3D8aeg@mail.gmail.com> <CAD6AjGTSSe+WaO-GFX5erjCVN27SLh=P6YN5uDBnCN7Wjcfb4g@mail.gmail.com> <CAO42Z2zQqw9prXFnVGsH3U2MWCe12L442Fk8cApMc0FbgkG6NA@mail.gmail.com> <26337.1604719436@localhost> <C57EA657-2364-4285-98D6-7BB5BC605809@consulintel.es>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <6fea651a-b716-a9ed-ba0b-e5f916df480d@joelhalpern.com>
Date: Sun, 08 Nov 2020 14:57:10 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.1
MIME-Version: 1.0
In-Reply-To: <C57EA657-2364-4285-98D6-7BB5BC605809@consulintel.es>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/6QGN6zrpu0ddho9CuFjIH2PxvFk>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 08 Nov 2020 19:57:15 -0000

Jorid, from what has been said, some ISPs do not use DHCPv6.  that's 
fair.  We actually told them they did not have to.
So I do not think it is fair or appropriate to claim that to solve the 
delegation problem they must use DHCPv6.

     What is not clear to me is why solving the delegation problem 
requires extending the allocation boundary past /64.  The draft on the 
v6ops agenda simply asserts that it is necessary.

Yours,
Joel

On 11/8/2020 2:46 PM, JORDI PALET MARTINEZ wrote:
> There are many ISPs offering IPv6. I never hear of any that doesn't use DHCPv6-PD to allocate /48, /56, some do /60, very few do /64 and we shall train them to understand that this is incorrect.
> 
> There is no technical neither cost reason (in terms of RIRs cost for getting a bigger IPv6 block), to allocate smaller prefixes for customers. The only reason they some time to /56 instead of /48 is "marketing" to differentiate business from residential customers. Nothing else.
> 
> Many ISPs do persistent prefixes.
> 
> Again, see RIPE-690 and https://indico.uknof.org.uk/event/41/contributions/542/attachments/712/866/bcop-ipv6-prefix-v9.pdf (look for the survey slides at the 2nd part).
> 
> Regards,
> Jordi
> @jordipalet
>   
>   
> 
> El 7/11/20 4:24, "ipv6 en nombre de Michael Richardson" <ipv6-bounces@ietf.org en nombre de mcr+ietf@sandelman.ca> escribió:
> 
> 
>      Mark Smith <markzzzsmith@gmail.com> wrote:
>          >> Why are the isps not giving more than one 64 ?
>          >>
>          >> Is it because the ietf made it hard and dhcp-pd is unworkable ,
> 
>          > There are multiple production residential deployments of DHCPv6-PD.
> 
>          > I worked on one that was deployed in 2010. I then used it for the next
>          > 8 years, and only moved away to another provider (and employer) where
>          > it is in beta.
> 
>      That's much cool.
>      It's very useful to hear of such successes!
> 
>      A question: was it easy to assign static subnets to the customers?
> 
>      My ISP initially statically routed my /56 to me, and then when they turned on
>      PD, they now send me three subnets. One statically, and apparently two by
>      DHCPv6-PD which they say they can't turn off/fix.  Very weird.
>      Well.... they aren't present today.
> 
>          > Telstra here in Australia have also been deploying it for a number of
>          > years in production.
> 
>          > Sky in the UK have deployed PD to 5 million subscribers.
> 
>          > PD is very workable, and a number of people have made it work.
> 
>      Maybe RIPE would do a survey to understand what has these things so
>      successful so that others can repeat it!
> 
>      --
>      Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>                 Sandelman Software Works Inc, Ottawa and Worldwide
>      --------------------------------------------------------------------
>      IETF IPv6 working group mailing list
>      ipv6@ietf.org
>      Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>      --------------------------------------------------------------------
> 
> 
> 
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>