RE: Last Call: RFC 6346 successful: moving to Proposed Standard

Christian Huitema <huitema@microsoft.com> Sat, 13 December 2014 20:09 UTC

Return-Path: <huitema@microsoft.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F921A1B40 for <ietf@ietfa.amsl.com>; Sat, 13 Dec 2014 12:09:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level:
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 ZSVQvTNpCgrH for <ietf@ietfa.amsl.com>; Sat, 13 Dec 2014 12:09:54 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0772.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:772]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 328C71A1B36 for <ietf@ietf.org>; Sat, 13 Dec 2014 12:09:54 -0800 (PST)
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (25.160.96.17) by DM2PR0301MB0654.namprd03.prod.outlook.com (25.160.96.16) with Microsoft SMTP Server (TLS) id 15.1.31.17; Sat, 13 Dec 2014 20:09:31 +0000
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([25.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([25.160.96.17]) with mapi id 15.01.0031.000; Sat, 13 Dec 2014 20:09:30 +0000
From: Christian Huitema <huitema@microsoft.com>
To: Douglas Otis <doug.mtview@gmail.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: RE: Last Call: RFC 6346 successful: moving to Proposed Standard
Thread-Topic: Last Call: RFC 6346 successful: moving to Proposed Standard
Thread-Index: AQHQDxusWN1rPAhXtk+RHKhHVhnHdJx+GygAgAswjICAAAtSAIAAKgyAgAAWe4CAAA6IgIAADRsAgAAHIwCAAAl+gIAAB8higAGqhQCAAPBJgIAAQWiAgAFWnJA=
Date: Sat, 13 Dec 2014 20:09:30 +0000
Message-ID: <DM2PR0301MB06550B62EC5D7A0AB24C7995A8610@DM2PR0301MB0655.namprd03.prod.outlook.com>
References: <547F451C.3010507@dcrocker.net> <D0AE1053.7AA8A%Lee@asgard.org> <AF1B977B-75D4-4AF2-B231-300AF2429317@nominum.com> <CAMm+Lwji9860CKaJB_9xi3ztiVUtP3NZ8AgO1wZAVTKVWW76Nw@mail.gmail.com> <CADC+-gR+sFUELOrdfVj5e3hW-KZoftotbhvEwF6aotZvq5wOkw@mail.gmail.com> <1DF3E368-D915-458C-8009-C508735D3C88@nominum.com> <5488FEE0.2030400@gmail.com> <84E9B4C0-A2E2-41BF-955A-1B125BBE63B1@nominum.com> <54890CD3.2050800@gmail.com> <20141211034501.1776A25434AE@rock.dv.isc.org> <20141212051204.GG39631@shrubbery.net> <548B42B5.50509@gmail.com> <8932FCC3-AC9C-4288-9E78-0BB2E1D05470@gmail.com>
In-Reply-To: <8932FCC3-AC9C-4288-9E78-0BB2E1D05470@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [24.16.156.113]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0654;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0654;
x-forefront-prvs: 04244E0DC5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377454003)(199003)(479174003)(51704005)(24454002)(33656002)(20776003)(31966008)(66066001)(101416001)(54206007)(19580405001)(19580395003)(92566001)(99396003)(2656002)(86362001)(54356999)(54606007)(50986999)(86612001)(64706001)(120916001)(87936001)(76176999)(77156002)(97736003)(93886004)(106116001)(105586002)(106356001)(99286002)(107046002)(68736005)(40100003)(62966003)(122556002)(74316001)(102836002)(46102003)(4396001)(76576001)(21056001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0654; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/nk9t-Zm2zZXXixz9csh8BKkYE5s
Cc: heasley <heas@shrubbery.net>, IETF Discussion Mailing List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Dec 2014 20:09:56 -0000

On Friday, December 12, 2014 3:26 PM, Douglas Otis wrote

> On Dec 12, 2014, at 11:32 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>
>> On 12/12/2014 18:12, heasley wrote:
>> ...
>>> I don't know anyone enchanted by v6.
>>  
>> Strange choice of word. I'm not in the least enchanted by IPv4
>> or by NAT44 either. I just know as a matter of fact that the
>> IPv4nternet ran out of addresses a while back and we have no
>> alternative but to fix it using IPv6. All the rest is details,
>> important details of course, but details.
>
> Dear Brian,
>
> Agreed.  One should not support the standardization of a v6 to v4 transitional scheme which significantly weakens
> protocol security by restricting available port assignments at various points within a path.  Suggested bit ranges of
> 7 to 10 bits significantly reduces protections otherwise obtained by random assignment.  As such, it makes this a 
> trivial matter for malefactors to deduce likely source entropies.  Although IPv6 creates different challenges, it
> provides the only viable long term standard moving forward.  In addition, NAT keep-alives tend to consume critical > mobile energy resources.

It would be interesting to study the effect of this port range assignment on applications. For example, a lot of the NAT traversal solutions rely on reserving ports for applications using UPNP IGD, PCP, or the management UI from the NAT. That's clearly going to break if the target port falls outside the range assigned to the NAT. But the applications have no official way to learn the range. The applications will thus have to implement ever more NAT traversal cleverness. So, this is by no means a harmless hack. It will have implications on a range of end systems. Personally, I don't see any urgency from changing the status away from experimental.

-- Christian Huitema