Re: IESG position on NAT traversal and IPv4/IPv6

jnc@mercury.lcs.mit.edu (Noel Chiappa) Mon, 15 November 2010 15:12 UTC

Return-Path: <jnc@mercury.lcs.mit.edu>
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 EFDAA28C174; Mon, 15 Nov 2010 07:12:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 uNlOUq3N6hqS; Mon, 15 Nov 2010 07:12:53 -0800 (PST)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 3132A28C143; Mon, 15 Nov 2010 07:12:52 -0800 (PST)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id E78456BE5C9; Mon, 15 Nov 2010 10:13:33 -0500 (EST)
To: ietf@ietf.org
Subject: Re: IESG position on NAT traversal and IPv4/IPv6
Message-Id: <20101115151333.E78456BE5C9@mercury.lcs.mit.edu>
Date: Mon, 15 Nov 2010 10:13:33 -0500
From: jnc@mercury.lcs.mit.edu
Cc: iesg@ietf.org, jnc@mercury.lcs.mit.edu
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 15:12:54 -0000

    > From: Hadriel Kaplan <HKaplan@acmepacket.com>

    > In one of the working group meetings this past week, when the group was
    > discussing a NAT traversal solution for their new protocol, an A-D
    > suggested they not spend much time on NAT traversal.
    > ...
    > I'd like to know if the IESG will push back on new protocols if they
    > attempt to work around NATs.

I'm somewhat surprised to hear this, because after the discussion a couple of
months back about IPv6 uptake, etc, I thought there was general agreement
(across the board, including both those pro- and anti-IPv6) that:

- For IPv6 to have any hope of broad deployment/acceptance, it _had_ to allow
interoperation between IPv6-only hosts, and the large amount of existing IPv4
Internet.

- The mechanism for doing that was, functionally, an IPv4-IPv6 NAT box (I
think the current incarnation is the Xlate stuff from BEHAVE).

At that time, in light of those observations, and the corollary observation
that no matter what the future winds up looking like (e.g. if the market
prefers to soldier on with IPv4 and NAT), there is going to be a lot of NAT in
it for a long time, I had actually suggested that we consider making 'works
across a NAT box' a _requirement_ for new protocol work.


If someone who considers that we should "not spend much time on NAT traversal"
could show me the flaw(s) in the above reasoning, I'd be most interested to
hear it(them).

	Noel