IETF Logo Mail Archive

RE: [EXTERNAL] Re: Extending a /64

"Manfredi (US), Albert E" <albert.e.manfredi@boeing.com> Sun, 08 November 2020 21:45 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 573413A0ED1 for <ipv6@ietfa.amsl.com>; Sun, 8 Nov 2020 13:45:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, RCVD_IN_MSPIKE_H2=-0.001, 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=boeing.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 8KiSDlL2S0GE for <ipv6@ietfa.amsl.com>; Sun, 8 Nov 2020 13:45:37 -0800 (PST)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 9845B3A0EDA for <ipv6@ietf.org>; Sun, 8 Nov 2020 13:45:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 0A8LjXG4003028; Sun, 8 Nov 2020 16:45:33 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1604871933; bh=uqLw/E+XZ/0Uj8JCZde2STnmVxxHjiRC8wS+SgJ4U8A=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=RfMJU3BFszN0xel4uMNx8Bo2u52MBzn+ZV4mU0qekYCby/4OlZdCiztiCSROM2irJ 1EYRrbU6sPx4NXwotCVwF70XqdOdKcvYbtvl4DH6Rypjw0zzu9EmPrX/82DCRmB7+a 86+VelhHVnAlxYUK4SKUFUAK9zmDOGD7buGYqU3wt5PT/2zvVGncaYIFHHl05TUNi1 PG0FBqdKYSBuGuHof077jAPkvl+q9BGavjKElV++p6xOQRryR2g3szoyR1PVdDelJW susoAbdzrTJODANTHzjt9aesMPJWpYTrMdfi6E1aCpPn+Iof6UqX5CFRN75DynWFpN 04iZkF/3eJqmw==
Received: from XCH16-01-12.nos.boeing.com (xch16-01-12.nos.boeing.com [144.115.66.70]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 0A8LjSda002014 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Sun, 8 Nov 2020 16:45:28 -0500
Received: from XCH16-01-11.nos.boeing.com (144.115.66.39) by XCH16-01-12.nos.boeing.com (144.115.66.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Sun, 8 Nov 2020 13:45:27 -0800
Received: from XCH16-01-11.nos.boeing.com ([fe80::a96c:5d85:1337:4323]) by XCH16-01-11.nos.boeing.com ([fe80::a96c:5d85:1337:4323%4]) with mapi id 15.01.2044.004; Sun, 8 Nov 2020 13:45:27 -0800
From: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>
To: Mark Smith <markzzzsmith@gmail.com>
CC: 6man WG <ipv6@ietf.org>
Subject: RE: [EXTERNAL] Re: Extending a /64
Thread-Topic: [EXTERNAL] Re: Extending a /64
Thread-Index: AQHWtc9C8daw9tHwyEigqT7INe4BOKm+1LMAgAAdKQD//8SpwIAAjwmA//98blA=
Date: Sun, 08 Nov 2020 21:45:27 +0000
Message-ID: <8fe9b163b4f64815b603b758620515da@boeing.com>
References: <005ECBB3-088B-4363-BB53-8D4AD25CA3D2@employees.org> <b468124f-f85b-7e20-a354-c6b7eaba3447@mccallumwhyman.com> <CAO42Z2wCN_obj-TpaUP23GRMUDwG6RyjsqhmY1ysAcSFigrLaw@mail.gmail.com> <a6d10c8f-b45e-a63b-e348-3b228007d889@mccallumwhyman.com> <b308d0105c3242488943bf233d2b900d@boeing.com> <CAO42Z2wiZct0dTaOEP586_06KM6pg0C2axq25KA3stmys1OgQA@mail.gmail.com>
In-Reply-To: <CAO42Z2wiZct0dTaOEP586_06KM6pg0C2axq25KA3stmys1OgQA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [144.115.204.6]
x-tm-snts-smtp: F0EBC62A8D5204FCEBA90E4138A5DB116FF8C2DF0356D5789A4407F2912A88412000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/4m-RMTdJCbs1C7OLkU8SuRTKnvc>
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 21:45:45 -0000

From: Mark Smith <markzzzsmith@gmail.com> 

> See RFC2993.
>
> See also the 3 part "The Trouble With NAT" articles, using network operation criteria.
>
> https://blog.apnic.net/author/mark-smith/

With IPv6, network prefix translation only (NPT), at the platform's interfaces with the ISPs.

"The fundamental constraint of NAT is that it prevents IP nodes attached to the same network from acting as peers of each other."

How so? I'm saying, these NAT problems, mostly experienced with NAPTs, either won’t happen, or can be managed in a platform with well-managed internal architecture. Is it a problem if state has to be maintained in such NAT (NPT) devices? I'd rather have that, than rely on the fixed ISPs, no? Plus, I'm not even using the NAT to provide some sort of inherent security benefit. Just using it to solve every single problem mentioned in these related threads. End to end connectivity can be retained.

Yes, the NPT boxes have to be managed reliably, but in these scenarios, that's preferable to expecting wither the end systems or the ISPs, to do everything predictably.

Bert

v2.23.0 | Report a Bug | By Email