From nobody Fri Aug 2 23:04:33 2019 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C0E1200E0 for ; Fri, 2 Aug 2019 23:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 bjPYYJfW7BUi for ; Fri, 2 Aug 2019 23:04:29 -0700 (PDT) Received: from mr85p00im-ztdg06011201.me.com (mr85p00im-ztdg06011201.me.com [17.58.23.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D78B1200A4 for ; Fri, 2 Aug 2019 23:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1564812267; bh=UG8zgtB5BP0bNVAONvaEm4LeVWsCS3uYb7mnIXDWLTY=; h=From:Message-Id:Content-Type:Subject:Date:To; b=YRgsj7U84YqYQJGryAiP3c8ltWqnRmt11T8jXdESymjjabkF9Wf2meTzkZQM3K5wu cJVkMSwFRILG7EA0s5H52YZWFiMxolxk/FuGDjogs6g/Nmi/023dovQi7tSMTS7y8t fY8YTLMikrJI3jdBtm67GzMKemn4hK36UW4+e7ZFx0JYCOGqAeHqAtP0Rt5Q0viEEb XwuFOMzGEerjCD4nzgePFEbev6b5zhTOjxdxFJEZdOQ6y4pkucNSSaPUyOtfbtB5xx 2g3f1uQl45Q9wsppOVoBYPeuOP/FrCGHcMRZsGCI4l1NqnpSSZtEHamY3lqN+7o0lq L0SYqzctLbVeg== Received: from [192.168.1.101] (m201-12.dsl.tsoft.com [198.144.201.12]) by mr85p00im-ztdg06011201.me.com (Postfix) with ESMTPSA id 92AC9400B9A; Sat, 3 Aug 2019 06:04:27 +0000 (UTC) From: Greg Skinner Message-Id: <73F0D75C-B411-4B8A-9FA1-AF30B54A0E0A@icloud.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A74AE58E-4675-4472-A1B1-2779FA7C0C67" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 2 Aug 2019 23:04:23 -0700 In-Reply-To: Cc: "sunset4@ietf.org" To: "George, Wes" References: X-Mailer: Apple Mail (2.3273) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-03_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1908030073 Archived-At: Subject: Re: [sunset4] Declaring IPv4 Historic X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2019 06:04:32 -0000 --Apple-Mail=_A74AE58E-4675-4472-A1B1-2779FA7C0C67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 22, 2016, at 5:21 AM, George, Wes = wrote: >=20 > From: sunset4 > on behalf of Greg Skinner = > > Date: Monday, March 21, 2016 at 9:09 PM >=20 > It occurred to me that there might be some people who have an active = interest in updating the IPv4 > standard in the not too distant future, such as those who want to use = 240.0.0.0/4 . >=20 > WG] I'd argue that they've missed their window, repeatedly. This comes = up [1] every [2] few [3] years [4]. It keeps failing to gain enough = momentum to go anywhere, for one primary reason: a large number of IP = stacks have hard-coded rules that disallow or otherwise treat 240/4 as = invalid IP space, so interfaces can't be configured with it, or will = drop packets they see with those addresses in the src/dst field. Even if = we changed the records tomorrow, there would be significant code and = configuration work necessary to enable it for any use on most platforms, = punch holes in firewalls, martian lists, etc. The same reason that it's = been difficult to get broader IPv6 deployment (it's expensive and = time-consuming to update legacy hardware and software and get to = ubiquitous enough deployment to make it broadly useful) is the same = thing that limits doing anything with Class E space today. In other = words, if people are willing to put in time to make changes to an IP = stack, especially on older gear, that's time better spent enabling the = current protocol version, rather than delaying the inevitable. The = further out on the IPv6 deployment curve we get, the less sense doing = something with 240/4 makes. > =20 > [=E2=80=A6] >=20 > Thanks, > =20 > Wes >=20 > [1] https://tools.ietf.org/html/draft-fuller-240space-02 = > [2] http://www.muada.com/drafts/draft-van-beijnum-v6ops-esiit-00.txt = > [3] https://tools.ietf.org/html/draft-wilson-class-e-02 = > [4] = http://packetlife.net/blog/2010/oct/14/ipv4-exhaustion-what-about-class-e-= addresses/ = >=20 >=20 For what it=E2=80=99s worth, the IPv4 Cleanup Project [5] aims to tackle = this issue. Arguably, they=E2=80=99re doing code and configuration = work. [5] https://github.com/dtaht/unicast-extensions = --Apple-Mail=_A74AE58E-4675-4472-A1B1-2779FA7C0C67 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Mar = 22, 2016, at 5:21 AM, George, Wes <wesley.george@twcable.com> wrote:

From: sunset4 <sunset4-bounces@ietf.org> on behalf of Greg Skinner = <gregskinner0@icloud.com>
Date: Monday, March = 21, 2016 at 9:09 PM

It occurred to me that there might be some people who = have an active interest in updating the IPv4
standard in the not too distant future, such as those who want to use 240.0.0.0/4.

WG] I'd argue that they've missed their window, = repeatedly. This comes up [1] every [2] few [3] years [4]. It keeps = failing to gain enough momentum to go anywhere, for one primary reason: = a large number of IP stacks have hard-coded rules that disallow or otherwise treat 240/4 as invalid IP space, so interfaces can't be = configured with it, or will drop packets they see with those addresses = in the src/dst field. Even if we changed the records tomorrow, there = would be significant code and configuration work necessary to enable it for any use on most platforms, punch holes in = firewalls, martian lists, etc. The same reason that it's been difficult = to get broader IPv6 deployment (it's expensive and time-consuming to = update legacy hardware and software and get to ubiquitous enough deployment to make it broadly useful) is the same = thing that limits doing anything with Class E space today. In other = words, if people are willing to put in time to make changes to an IP = stack, especially on older gear, that's time better spent enabling the current protocol version, rather than delaying the = inevitable. The further out on the IPv6 deployment curve we get, the = less sense doing something with 240/4 makes.
 
[=E2=80=A6]

Thanks,
 
Wes

[1] https://tools.ietf.org/html/draft-fuller-240space-02
[2] http://www.muada.com/drafts/draft-van-beijnum-v6ops-esiit-00.tx= t
[3] https://tools.ietf.org/html/draft-wilson-class-e-02
[4] http://packetlife.net/blog/2010/oct/14/ipv4-exhaustion-what-abo= ut-class-e-addresses/



For what = it=E2=80=99s worth, the IPv4 Cleanup Project [5] aims to tackle this = issue.  Arguably, they=E2=80=99re doing code and configuration = work.

[5] https://github.com/dtaht/unicast-extensions

= --Apple-Mail=_A74AE58E-4675-4472-A1B1-2779FA7C0C67--