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> Wed, 12 July 2017 18:32 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 636A9131780 for <ipv6@ietfa.amsl.com>; Wed, 12 Jul 2017 11:32:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 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] 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 w3rXNlMPQS6u for <ipv6@ietfa.amsl.com>; Wed, 12 Jul 2017 11:32:52 -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 1793C13177E for <ipv6@ietf.org>; Wed, 12 Jul 2017 11:32:51 -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 v6CIWojq046330; Wed, 12 Jul 2017 11:32:50 -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 v6CIWnk1046325 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 12 Jul 2017 11:32:49 -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; Wed, 12 Jul 2017 11:32:48 -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; Wed, 12 Jul 2017 11:32:48 -0700
From: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
To: Mark Smith <markzzzsmith@gmail.com>
CC: 6man WG <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+SDP3OTJu1pEb0ubfyaiRp6wkqJNwW2AgAAMmoCAAFh6gP//l4BAgADKDwCAAFSoEIAA6HsAgAAt/wD//43p8IAAyDmAgAAyBvA=
Date: Wed, 12 Jul 2017 18:32:48 +0000
Message-ID: <c7b140bf69104cd3877a7da03fbf17e7@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>
In-Reply-To: <CAO42Z2x7ER2fUietjT3Ns-jpCqscCmVDVubiM0Dgw1_L0bkw=A@mail.gmail.com>
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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/NqArYdmLETPoEBRcBPBUfwQNEaY>
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: Wed, 12 Jul 2017 18:32:53 -0000

-----Original Message-----
From: Mark Smith [mailto:markzzzsmith@gmail.com] 

> What are the specific drawbacks or advantages of thermometer
> and thermostats not having 64 bit IIDs?

I'm fairly certain that if the IETF could somehow guarantee that every "site" (however that's defined) were allocated a /48, there wouldn't be so much of an issue. This is another one of those arguments that keeps cycling, though. The pro-64-bit boundary camp says that there are plenty of /48s to go around. Fine and good, but the other camp says, how come /48s are not being handed out, then? So it's a question of theory vs reality.

The drawbacks are generic, but let's take HVAC. The system gets upgraded, from a relatively old school design, with a few interfaces to the platform network, and much hard wiring behind these, to several hundred networked interfaces within the HVAC subsystem.

With a hard 64-bit boundary, I'm constrained to creating a flat address space for the upgraded HVAC system, with all these little gizmos hanging off the platform network. That can work, because 64-bit IIDs allow for lots of devices. Alternatively, I can create new /60s or /62s, for this upgraded HVAC system, assuming I have enough prefix space to work with!

But with IID flexibility, I can partition the upgraded HVAC system into its own subnets, behind the previous platform network interfaces to HVAC, with no trouble at all, even if the entire platform was only allocated, say, a /56, or for that matter, even a /64.

Of course, the other option is to expand using ULAs, but then, that's "so IPv4."

Bert

v2.23.0 | Report a Bug | By Email