IETF Logo Mail Archive

Re: [Taps] TCP components

Joe Touch <touch@isi.edu> Tue, 16 June 2015 23:59 UTC

Return-Path: <touch@isi.edu>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C081B2B75 for <taps@ietfa.amsl.com>; Tue, 16 Jun 2015 16:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.61
X-Spam-Level:
X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 3fW1VRaKUo5f for <taps@ietfa.amsl.com>; Tue, 16 Jun 2015 16:59:36 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2DA1B2B84 for <taps@ietf.org>; Tue, 16 Jun 2015 16:59:35 -0700 (PDT)
Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t5GNwN38002779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 Jun 2015 16:58:25 -0700 (PDT)
Message-ID: <5580B81F.2050906@isi.edu>
Date: Tue, 16 Jun 2015 16:58:23 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: gorry@erg.abdn.ac.uk, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
References: <5579768E.5060402@tik.ee.ethz.ch> <2e1ca6a7e239e671b7516431ad5db93c.squirrel@erg.abdn.ac.uk>
In-Reply-To: <2e1ca6a7e239e671b7516431ad5db93c.squirrel@erg.abdn.ac.uk>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/lH1vuaMb98AhYWWd2NwRWv1FiKo>
Cc: Brian Trammell <ietf@trammell.ch>, "taps@ietf.org" <taps@ietf.org>, touch@isi.edu
Subject: Re: [Taps] TCP components
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jun 2015 23:59:37 -0000


On 6/11/2015 5:30 AM, gorry@erg.abdn.ac.uk wrote:
...
>> - Port multiplexing, with application-to-port mapping during connection
>> setup:
> 
> GF: Thinking on this, is application-to-port mapping really a TCP
> function? port-mapping is similar in other transports, and doesn't really
> have any different support in TCP (contrast to the Service Code in DCCP)

The assumption of app-to-port mapping is part of how assigned ports are,
well, assigned.

>> 	Note that in the presence of network address and port translation (NAPT),
>> TCP
>> ports are
>> 	in effect part of the endpoint address for forwarding purposes.
>>
> GF: This is the case only for those middle boxes that do NAPT,
> load-ballancing etc, saying they are part of the endpoint address is to me
> confusing forwarding by middle boxes from forwarding by routers - I'd
> prefer to be more careful here.

Ports are part of the connection identifier, in conjunction with the
endpoint address.

The fact that NATs or any other devices remap, translate, or overload
that function (i.e., using it for forwarding decisions) is not relevant
to TCP's view of these values or to the service TCP provides, IMO.

Joe

v2.23.0 | Report a Bug | By Email