Re: [tae] [tsv-area] Transport negotiation

Joe Touch <touch@ISI.EDU> Wed, 10 December 2008 22:12 UTC

Return-Path: <tae-bounces@ietf.org>
X-Original-To: tae-archive@ietf.org
Delivered-To: ietfarch-tae-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3560A28C1DE; Wed, 10 Dec 2008 14:12:43 -0800 (PST)
X-Original-To: tae@core3.amsl.com
Delivered-To: tae@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 554913A69A2; Wed, 10 Dec 2008 14:12:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 E2Mzb7FdTplu; Wed, 10 Dec 2008 14:12:40 -0800 (PST)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 884EB3A69A0; Wed, 10 Dec 2008 14:12:40 -0800 (PST)
Received: from [128.9.176.55] (c1-vpn15.isi.edu [128.9.176.55]) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id mBAMC1Hr006439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Dec 2008 14:12:03 -0800 (PST)
Message-ID: <49403EB0.7050200@isi.edu>
Date: Wed, 10 Dec 2008 14:12:00 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Stuart Cheshire <cheshire@apple.com>
References: <3BB334D8-B00C-48C1-ACBF-4D09576DEADF@mpi-sws.org> <492C7F97.3030000@isi.edu> <EDCC4CF2-DC3C-409F-8F99-3BE51BAE4111@surrey.ac.uk> <492DE8AD.1090300@isi.edu> <7DA33930-1767-492B-807E-7A7DA661AFE9@apple.com> <5AE49824-74B1-4ABE-BBD4-7DEAFA348245@apple.com> <3F1AB633-7E17-47C4-B126-D8D872B552C5@apple.com> <0191F3F9-CC3D-4925-90BC-15BC966FE012@apple.com> <78ACC2CD-C6E6-46A3-B198-0C0284917E94@apple.com> <494002AB.6080605@isi.edu> <9CF98731-3A97-4056-AF33-64FC43E363CC@apple.com>
In-Reply-To: <9CF98731-3A97-4056-AF33-64FC43E363CC@apple.com>
X-Enigmail-Version: 0.95.7
X-MailScanner-ID: mBAMC1Hr006439
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tae@ietf.org, tsv-area@ietf.org
Subject: Re: [tae] [tsv-area] Transport negotiation
X-BeenThere: tae@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Architecture Evolution <tae.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tae>, <mailto:tae-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/tae>
List-Post: <mailto:tae@ietf.org>
List-Help: <mailto:tae-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tae>, <mailto:tae-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tae-bounces@ietf.org
Errors-To: tae-bounces@ietf.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Stuart Cheshire wrote:
> On 10 Dec, 2008, at 09:55, Joe Touch wrote:
>
>> IMO, NATs need to understand the demultiplexing that is designed to be
>> internal to a host exactly because of what a NAT is and what it does. It
>> doesn't make sense to be to bemoan that fact.
>>
>> Joe
>
> I can't tell which side you are arguing. Do you believe that:
>
> (a) demultiplexing (i.e. port numbers) should be duplicated by every
> transport layer, or
> (b) demultiplexing (i.e. port numbers) should be done once, at a shared
> lower layer?

Regarding NATs, I think that demultiplexing of port numbers should be
done inside the end host, and that NATs necessarily need to peek at
these numbers in 'layer violating ways'.

The question you're asking is clearer now - i.e., what is the demux order:

	1) IPaddr, transportproto, port

	2) IPaddr, port, transportproto

AFAICT, the demultiplexing is really:

	3) IPaddr, [transportproto, port]

I.e., the second demuxing (after IP address) includes both the transport
protocol and the port as a pair - whether done in a NAT or in the end
system. I understand that you want to decouple the two, but port numbers
aren't defined independently of transport protocol. Regardless of what
order you do them in, whatever does one needs to do both AFAICT.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklAPq8ACgkQE5f5cImnZrudxwCeP81zC7vgYK1hihpii3zP8Q51
trkAn0y5rBgnDYRkc2sYEb70AGjREzAC
=epIh
-----END PGP SIGNATURE-----
_______________________________________________
tae mailing list
tae@ietf.org
https://www.ietf.org/mailman/listinfo/tae