IETF Logo Mail Archive

Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios)

Kristian McColm <kristianmccolm@hotmail.com> Fri, 22 February 2019 02:25 UTC

Return-Path: <kristianmccolm@hotmail.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 C6FD912F295; Thu, 21 Feb 2019 18:25:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.125
X-Spam-Level:
X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 vt4YrQJDb6zT; Thu, 21 Feb 2019 18:25:47 -0800 (PST)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-oln040092007010.outbound.protection.outlook.com [40.92.7.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED43B126F72; Thu, 21 Feb 2019 18:25:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lpbGZZ0TfRvlFXsJEi4jJhdhk87LbaohgrUxE7D4HDg=; b=vAJbkKgc/xXw3Jv88xk1clHvjYhYkWPwFl6DIGmrVHL069qlEmQ+6H7dPvRmJID1JjmXOV8lC07QjUWKWV1x6RE3KfJfIphr9d1yfhcfwgd6Zby+74N3Bf8VLv+wbxibiMbCUuXN9Wa7iSu6Oj3C3yJ26gcz9/f1ASShyEEGtjZTu/XM7nUDPLg6uWRbNk+9RN93D+jdXE60XF3cRPU8FKWYHX/CS2/gOGBWED9pOQp6nJuDyuc4Cs6BqjNvFdEIjGEPa+Jzf20LJHO8l5fpSdWIPlzho/eqnvaUJDjAONtTMBEXiDAWF3ohqUOfFv+paZORVslsoYsux0CdX4JmFQ==
Received: from DM3NAM03FT031.eop-NAM03.prod.protection.outlook.com (10.152.82.53) by DM3NAM03HT192.eop-NAM03.prod.protection.outlook.com (10.152.83.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13; Fri, 22 Feb 2019 02:25:46 +0000
Received: from DM6PR04MB4009.namprd04.prod.outlook.com (10.152.82.54) by DM3NAM03FT031.mail.protection.outlook.com (10.152.82.199) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Fri, 22 Feb 2019 02:25:46 +0000
Received: from DM6PR04MB4009.namprd04.prod.outlook.com ([fe80::11d2:230b:c319:5968]) by DM6PR04MB4009.namprd04.prod.outlook.com ([fe80::11d2:230b:c319:5968%5]) with mapi id 15.20.1643.016; Fri, 22 Feb 2019 02:25:45 +0000
From: Kristian McColm <kristianmccolm@hotmail.com>
To: Fernando Gont <fgont@si6networks.com>, Tom Herbert <tom@herbertland.com>
CC: IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios)
Thread-Topic: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios)
Thread-Index: AQHUylQ7xClo1pMmD0qbB4iWLKyk0aXrFpQAgAAAlH0=
Date: Fri, 22 Feb 2019 02:25:45 +0000
Message-ID: <DM6PR04MB4009E6096E8CF525931D46A5DD7F0@DM6PR04MB4009.namprd04.prod.outlook.com>
References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <B6E2EC33-EEAF-40D0-AFCC-BDAFA9134ACD@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <CAKD1Yr0HBG+rhyFWg9zh0t3mW486Mjx9umjn+CRqAZg4z9r0dg@mail.gmail.com> <20190221073530.GT71606@Space.Net> <CAO42Z2wmB2W52b4MZ2h9sW5E9cQKm-HRjyf--q8C26jezS7LXQ@mail.gmail.com> <a73818d31db7422b99a524bc431b00ed@boeing.com> <CAO42Z2z9-48Gbb_Exf+oWUqDO=axSLpZBtqeDcxkAoFq5OziGw@mail.gmail.com> <CALx6S3624hnGauG1HaSWPMvQw0t2Q5R3gb8W4R8w3kuK7dcrWQ@mail.gmail.com> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <1470063a-db4b-d2fc-a709-68e30736fbed@si6networks.com>, <CALx6S36K5v9gusorEvj_uJjW4YwgERGdoWZOABREMpnqhJWJPw@mail.gmail.com>
In-Reply-To: <CALx6S36K5v9gusorEvj_uJjW4YwgERGdoWZOABREMpnqhJWJPw@mail.gmail.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:FD7DCC5DF52469A18CF134B9E76309A1BF6A4FC5062AE388FA0FA432E3186F9C; UpperCasedChecksum:5BD7FEC2A1F88B61F4F147C15F1FD3799375ED61863D8B96DEF0DA8B539E688E; SizeAsReceived:7851; Count:45
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [rLvYIw2QqMYWUewb8ipSIoSeuKMnqeIC]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(20181119070)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322404)(2017031324274)(2017031323274)(1601125500)(1603101475)(1701031045); SRVR:DM3NAM03HT192;
x-ms-traffictypediagnostic: DM3NAM03HT192:
x-microsoft-antispam-message-info: ZAP9qzdFJGpUcL0ENfulOJJY8rBLinZsQB9bnwEgphwUjFm/8xvWSNN3WvBMrgyh
Content-Type: multipart/alternative; boundary="_000_DM6PR04MB4009E6096E8CF525931D46A5DD7F0DM6PR04MB4009namp_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 0746e09b-7d67-4841-1f81-08d6986d0d19
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2019 02:25:45.7570 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3NAM03HT192
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/_dLE0KwFKO4cXBDTub8Py-XbDaU>
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: Fri, 22 Feb 2019 02:25:49 -0000

Amen to that. Make the end user devices responsible for their own security.
________________________________
From: v6ops <v6ops-bounces@ietf.org> on behalf of Tom Herbert <tom@herbertland.com>
Sent: Thursday, February 21, 2019 9:23:38 PM
To: Fernando Gont
Cc: IPv6 Operations; 6man@ietf.org; JORDI PALET MARTINEZ
Subject: Re: [v6ops] NAT debate (Re: A common problem with SLAAC in "renumbering" scenarios)

On Thu, Feb 21, 2019 at 6:13 PM Fernando Gont <fgont@si6networks.com> wrote:
>
> On 21/2/19 22:58, JORDI PALET MARTINEZ wrote:
> >
> >     I agreee with that with one exception. I believe that NAT/IPv4 can
> >     offer better privacy in addressing than IPv6 given current addess
> >     allocation methods.
> >
> > I'm for as much privacy as possible, however, not at the cost of things such as:
> > - Unnecessary complexity increase
> > - Moving from peer-to-peer to client-server for everything
> > - Single point of failure
> > - Increasing the attacks chances by reducing the surface to the servers
> > - Increase the complexity of app development
> > - Complexity to host services in "clients"
> > - Complexity to use "freely" and "efficient" DNS
> > - etc
>
> There are two protocols associated with NATs:
> 1) Apps that incorporate IP addresses and ports in the app protocol
> require an ALG
> 2) Because of of the "only allow outgoing connections" side-effect of
> NATs, you need UPnP to open holes in the NAT, or some NAT traversal
> technique.
>
>
> "1)" goes away when you remove the NAT.
>
> "2)" does not if you replace the NAT with a stateful firewall that only
> allows outgoing connections. -- the majority of the IPv6 deployments
> I've seen use this policy/model. And, of course, this is also a single
> point of failure, will also increase application complexity, etc., etc.,
> etc.

So we need to eliminate stateful firewalls as well as NAT...

Tom

>
>
>
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

v2.23.0 | Report a Bug | By Email