IETF Logo Mail Archive

RE: IPv6 Routing & ND vs. Addressing, (Was: Re: <draft-ietf-6man-rfc4291bis-09.txt>)

"Manfredi, Albert E" <albert.e.manfredi@boeing.com> Thu, 13 July 2017 18:16 UTC

Return-Path: <albert.e.manfredi@boeing.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 3D6DD131734 for <ipv6@ietfa.amsl.com>; Thu, 13 Jul 2017 11:16:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 B3GQPfUItw7M for <ipv6@ietfa.amsl.com>; Thu, 13 Jul 2017 11:16:08 -0700 (PDT)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (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 B3AE9129B05 for <ipv6@ietf.org>; Thu, 13 Jul 2017 11:16:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v6DIG8ih002928; Thu, 13 Jul 2017 11:16:08 -0700
Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6DIG3NP002884 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Thu, 13 Jul 2017 11:16:04 -0700
Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 13 Jul 2017 11:16:03 -0700
Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Thu, 13 Jul 2017 11:16:03 -0700
From: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
To: Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: RE: IPv6 Routing & ND vs. Addressing, (Was: Re: <draft-ietf-6man-rfc4291bis-09.txt>)
Thread-Topic: IPv6 Routing & ND vs. Addressing, (Was: Re: <draft-ietf-6man-rfc4291bis-09.txt>)
Thread-Index: AQHS+8OVa2oiBiwIAEuVrerXjOp/r6JSC+xg
Date: Thu, 13 Jul 2017 18:16:03 +0000
Message-ID: <b6de67ac86804b308003454f9dc7607e@XCH15-06-11.nw.nos.boeing.com>
References: <CAN-Dau2zgthR2w9e5ZVUdGc-vm+YvK2uTUJ8O=vrcv0jNc58RA@mail.gmail.com> <CAKD1Yr2+Si_tzNF8p6ASf4=StgFSX9Gm3TEj9iiqdE2gHQaNmQ@mail.gmail.com> <CAN-Dau03r_CKW53kegaLa=F_R_RG4cWaCT1j6idrqPm9UuN03A@mail.gmail.com> <5963BF27.1050300@foobar.org> <ff09ffcd-df65-4033-8018-fbe7ae98cff8@gmail.com> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <CAN-Dau1bxm5y0v_6kUBc_ym39bSSxepjdwrzcS7YHWD=CV9-bw@mail.gmail.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <CAO42Z2x+282VK7nMFHjcCz9tBmJ_=d4OhkiRZFZDLcZhakGB1Q@mail.gmail.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <CAO42Z2x7ER2fUietjT3Ns-jpCqscCmVDVubiM0Dgw1_L0bkw=A@mail.gmail.com> <c7b140bf69104cd3877a7da03fbf17e7@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> <m1dVbRc-0000GQC@stereo.hq.phicoh.net>
In-Reply-To: <m1dVbRc-0000GQC@stereo.hq.phicoh.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.136.248.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/mDJ1zN34_dUTj5VohnNnSd_wmDo>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 13 Jul 2017 18:16:10 -0000

-----Original Message-----
From: pch-b7900FA3D@u-1.phicoh.com [mailto:pch-b7900FA3D@u-1.phicoh.com] On Behalf Of Philip Homburg

>> The problem is that over time, way more IP addresses become necessary,
>> not just a few more. It's because so many more systems adopt IP, and
>> become so much smarter than they used to be. So you need flexibility
>> to expand, not just in number of connected devices, but also in the
>> architecture of the network.
>
> Using pseudo-random IIDs comes with the risk of collisions. So you have
> to waste lots of bits to get that risk down to an acceptable level.

With DHCP, or with static configuration of hosts, you don't have any risk of collisions. And the risk of collisions with fewer than 64 bits is not necessarily a problem. The risk of collisions with 48 bits should be acceptable too. However, if we continue the self-imposed limit of 64 bit IIDs for SLAAC, that becomes a non-problem.

I'm belaboring here, but if, at the same time, "sites" (again, however that is defined) are assigned /64s, or /56s, and we continue to insist that IIDs must be 64 bits, then the plain result is that we're back to where we were with IPv4. Expansion becomes a problem. Either you go back and get more address space, or you use IPv4-like techniques. And to avoid the conclusions people arrived at last time, I'm talking about using ULAs. Just like it was with private addresses in IPv4.

The rationale people give that /48s should be plentiful may be fine. Problem is, it becomes irrelevant, if /48s are not handed out. The IETF has no police powers here, so that rationale is not reflecting reality.

> However, since the mid 90s we have a protocol for dense allocation of
> addresses. Where in the 64-bit IID space you can fit an entire universe.

In a flat universe, maybe. No one is disputing that 64 bit IIDs allow for many hosts in a single subnet prefix. But we also discovered in the 1980s and 1990s how bad it is to create gymongous IP subnets.

Bert

v2.23.0 | Report a Bug | By Email