Re: [tram] IPv4 and IPv6 allocations

Simon Perreault <simon.perreault@viagenie.ca> Wed, 19 February 2014 15:42 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6837F1A0206 for <tram@ietfa.amsl.com>; Wed, 19 Feb 2014 07:42:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] 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 8bpuo2O1Roql for <tram@ietfa.amsl.com>; Wed, 19 Feb 2014 07:42:06 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7931A01DE for <tram@ietf.org>; Wed, 19 Feb 2014 07:42:06 -0800 (PST)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 26EC7403C0 for <tram@ietf.org>; Wed, 19 Feb 2014 10:42:03 -0500 (EST)
Message-ID: <5304D0CA.9020201@viagenie.ca>
Date: Wed, 19 Feb 2014 10:42:02 -0500
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: tram@ietf.org
References: <CAJjP_Q9qQ-o=q+UVo=3Q2w2mnUpOG=ihPiGDMRPfrDNhzpiTNg@mail.gmail.com>
In-Reply-To: <CAJjP_Q9qQ-o=q+UVo=3Q2w2mnUpOG=ihPiGDMRPfrDNhzpiTNg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/pbki1u-EE-6z9cLDNG085VPCeFI
Subject: Re: [tram] IPv4 and IPv6 allocations
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Feb 2014 15:42:08 -0000

Le 2014-02-19 10:31, Mallinath Bareddy a écrit :
> Hi All,
> 
>>From RFC 5766, 
>      Both the server and client keep track of a value known as the
> 
>    5-TUPLE.  At the client, the 5-tuple consists of the client's host
>    transport address, the server transport address, and the transport
>    protocol used by the client to communicate with the server.  At the
>    server, the 5-tuple value is the same except that the client's host
>    transport address is replaced by the client's server-reflexive
>    address, since that is the client's address as seen by the server.
> 
> 
> 
> I have a scenario where Turn client is sending IPv4 and a IPv6 (using REQUESTED-ADDRESS-FAMILY attribute) allocation requests from the same host transport address. The reason to send IPv6 allocation request is to connect to a IPv6 only client.
> 
> 
> 
> From above definition both allocation requests will result in same 5-tuple at the server.

No. There can be only one allocation per 5-tuple.

> How does TURN server demux requests from client, leading to the proper allocation object?

Have the client use a different source port.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca