IETF Logo Mail Archive

Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-09.txt

Derek Fawcus <dfawcus+lists-tsvwg@employees.org> Wed, 15 June 2016 11:11 UTC

Return-Path: <dfawcus@employees.org>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9722F12D1A6 for <tsvwg@ietfa.amsl.com>; Wed, 15 Jun 2016 04:11:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.92
X-Spam-Level:
X-Spam-Status: No, score=0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FAKE_REPLY_C=1.486, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=dfawcus+lists-tsvwg@employees.org header.d=employees.org
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 YNM5ZAE-yksM for <tsvwg@ietfa.amsl.com>; Wed, 15 Jun 2016 04:11:41 -0700 (PDT)
Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2EE512D18E for <tsvwg@ietf.org>; Wed, 15 Jun 2016 04:11:40 -0700 (PDT)
Received: from cowbell.employees.org ([65.50.211.142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jun 2016 11:11:39 +0000
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id B81D09CC7C; Wed, 15 Jun 2016 04:11:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=date:from :to:cc:subject:message-id:mime-version:content-type; s= selector1; bh=9Nd8tey7CrAbndz0mv7mt+XgUco=; b=Ghvv72TmFQBg/Vclr2 qFZvKhVcxV80DVCcgRcFLZKjp7TnjlJL7bhZhoZiGo4Z4glTkyWT2QePZlW77mDA 38TXD8b1BQ7fr9L1EGhN26+jNkwlWLUegEdHsJl9IWLHijqri+w/DjW2JUSqlh51 Vfqk1e464R9QBkEbAv1pLDEEU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=date:from :to:cc:subject:message-id:mime-version:content-type; q=dns; s= selector1; b=EMXyPizyilPgx8RybToj2/tzkW2i5+j8rlzo6w1i4XZ+gB+g78L 354G1U/WebPVigGbAG3eNQQK7KiHSsXRnnN+vlEpQph7PEO5J0T2taij3KdjDLTe R754mdxRkO35uedI8kMdpxy6Fect9qYm8AYDXgH/XwdnKFQ6HYigRCmY=
Received: by cowbell.employees.org (Postfix, from userid 1736) id A1A5A9CC51; Wed, 15 Jun 2016 04:11:38 -0700 (PDT)
Date: Wed, 15 Jun 2016 12:11:38 +0100
From: Derek Fawcus <dfawcus+lists-tsvwg@employees.org>
To: tsvwg@ietf.org
Message-ID: <20160615111138.GA65681@cowbell.employees.org>
Mail-Followup-To: tsvwg@ietf.org, randall@lakerest.net, tuexen@fh-muenster.de
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/6echImZUZhpsKYLQtVE0zcaFZz8>
Cc: tuexen@fh-muenster.de, randall@lakerest.net
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-09.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jun 2016 11:11:42 -0000

On Wed, May 18, 2016 at 01:13:46pm -0700, internet-drafts@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Transport Area Working Group of the IETF.
> 
>         Title           : Stream Control Transmission Protocol (SCTP) Network Address Translation Support
>         Authors         : Randall R. Stewart
>                           Michael Tuexen
>                           Irene Ruengeler
> 	Filename        : draft-ietf-tsvwg-natsupp-09.txt
> 	Pages           : 44
> 	Date            : 2016-05-18

So does anyone know if there are any host stacks which support the above extensions yet?
(Even if only process space implementations).

i.e. processing the extended ABORT chunk (with M bit set),  and will use the Port Number
Collision Error Cause to trigger a re-attempt with a new port number?

Basically the situation in section 6.4 plus the handling in section 6.3.
I note that 6.3 mentioned re-attemting with a new V-Tag,  but 6.4 does not mention
the client re-attemping with a new port number (assuming it was an ephemeral port).

As to why:
   Assume a CGN where the map of private addr+port <=> public add+port assignments
   is being shared for TCP/UDP/UDP-Lite/DCCP, it would be useful to be able to use
   the same map for SCTP.

DF

v2.23.0 | Report a Bug | By Email