Re: IESG position on NAT traversal and IPv4/IPv6

Hadriel Kaplan <HKaplan@acmepacket.com> Mon, 15 November 2010 16:40 UTC

Return-Path: <HKaplan@acmepacket.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50B0D28C194; Mon, 15 Nov 2010 08:40:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.028
X-Spam-Level:
X-Spam-Status: No, score=-1.028 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXcCducefcgB; Mon, 15 Nov 2010 08:40:53 -0800 (PST)
Received: from ETMail2.acmepacket.com (unknown [216.41.24.9]) by core3.amsl.com (Postfix) with ESMTP id 68A8B3A6B98; Mon, 15 Nov 2010 08:40:53 -0800 (PST)
Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 15 Nov 2010 11:41:33 -0500
Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Mon, 15 Nov 2010 11:41:33 -0500
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: David Harrington <ietfdbh@comcast.net>
Date: Mon, 15 Nov 2010 11:41:31 -0500
Subject: Re: IESG position on NAT traversal and IPv4/IPv6
Thread-Topic: IESG position on NAT traversal and IPv4/IPv6
Thread-Index: AcuE4/XVdavLRU5KSw2nzuZtJ6HaFQ==
Message-ID: <6AC7D5FA-18D4-4835-9BAD-1545E686CF75@acmepacket.com>
References: <F443844F-67B6-418F-9E32-B2F498686650@acmepacket.com> <AANLkTimnQo=gAXa3FQWWfTp004t-Uv_RDzgOd=30Q49b@mail.gmail.com> <964D24B7092B4686A29005ACBBBCE6C4@23FX1C1>
In-Reply-To: <964D24B7092B4686A29005ACBBBCE6C4@23FX1C1>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAUA=
Cc: "iesg@ietf.org" <iesg@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 15 Nov 2010 16:40:54 -0000

On Nov 15, 2010, at 7:21 AM, David Harrington wrote:

> I believe I'm the AD you are referring to.

Yes but I wasn't trying to pick on anyone - just trying to understand what the official IESG position is.


> I never said "the IESG is discouraging NAT traversal mechanisms for new protocols,"

Nope, not in quotes - which was why I didn't put it in quotes.  That was my interpretation of the comments (and I think the interpretation of others in the room, given what the presenter and next person up to the mic said in response).  But absolutely I could have misinterpreted the comments, which was why I was asking for the official IESG position.


> I said (feel free to check the session recording, (ch3-fri-am 1:25), which is where I got the following text from):

I did check the session recording, multiple times, before sending the email.  I also considered not sending the email at all, because I was worried it would become about what you said.  I don't care what you said - you weren't reading a prepared speech. :) 
What I'm more concerned about is what the IESG position is, if there is one.


> If your core protocol ONLY works with an IPv4 NAT'd transport, I believe you will get pushback.

I didn't see the ppsp slides as saying it required a NAT for the protocol to work.  I don't even know how that could work - would it check to make sure there is a NAT??


> The solution should also be able to work in other environments, such as an un-NAT'd IPv6 environment.

Absolutely.  And it should work in environments with IPv6 NATs, and in environments with IPv6 firewalls, and in environments with IPv6 consumer gateways which block inbound packets until an outbound packet opens a pinhole.  All of those fundamentally require the same sort of NAT traversal as for IPv4.  None of us have a crystal ball to tell us how IPv6 will end up being deployed.

Having said all that, I'm curious what makes the IESG believe they have the authority to impose any such future vision/goal on WG proposed standards.  I don't believe RFC 3710, 2026 nor 2418 gives the IESG such discretion.  I could be misreading those RFCs, but I believe the criteria the IESG should be using are in RFC 2026 sections 4.1.1 and 6.1.2, and they're fairly limited.

-hadriel