Re: [BEHAVE] (no subject)

"cb.list6" <cb.list6@gmail.com> Wed, 26 June 2013 13:56 UTC

Return-Path: <cb.list6@gmail.com>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7345D21F9079 for <behave@ietfa.amsl.com>; Wed, 26 Jun 2013 06:56:54 -0700 (PDT)
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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24HfwGlB8duo for <behave@ietfa.amsl.com>; Wed, 26 Jun 2013 06:56:53 -0700 (PDT)
Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2813521F9BC9 for <behave@ietf.org>; Wed, 26 Jun 2013 06:56:36 -0700 (PDT)
Received: by mail-wg0-f45.google.com with SMTP id j13so10675000wgh.24 for <behave@ietf.org>; Wed, 26 Jun 2013 06:56:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8+pVCZXvi8AtQ5P2Wx8+HGRCoSkQwi2TlODXquKDswo=; b=PmiAcbAlyU4zEstKQAfDBfiq5t5P6YJHHyVbkUkCI5PsaeUR6A4k35jrL6wmxdkAL3 LY8rWD+tvTUeDUqEPrwwHdfE9X2H2AEBAI8+FtI81V/VKfALGFecW5crHz6aLUdZ+IEU eqWxPW01zfWoP7XaBhWsmUi+1xngssKUsn4Q0P5IaNJhVIwO91nKuKFAFkVjgt2Js2cz 53u5vSiyg/7O0heUdkerc0e2cE7me/8pdqgivanzimBY4E5WTFrXAZZcFjBdsv+0hFQq WIOIZr1uTFOU7tQ/6Q8WsdTv78OTS7iMUH9sbZSwKPzuLEWNA/pjuuX5tcurdCluScxr 7IPQ==
MIME-Version: 1.0
X-Received: by 10.180.12.11 with SMTP id u11mr2673581wib.61.1372254993322; Wed, 26 Jun 2013 06:56:33 -0700 (PDT)
Received: by 10.194.240.36 with HTTP; Wed, 26 Jun 2013 06:56:33 -0700 (PDT)
Received: by 10.194.240.36 with HTTP; Wed, 26 Jun 2013 06:56:33 -0700 (PDT)
In-Reply-To: <51CAA20F.4070307@viagenie.ca>
References: <CB1B483277FEC94E9B58357040EE5D02325A6E93@xmb-rcd-x15.cisco.com> <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <f8741fad1af1cee094de9c59408b7425@cacaoweb.org> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca>
Date: Wed, 26 Jun 2013 06:56:33 -0700
Message-ID: <CAD6AjGRwD+oZVyaR+WAN-aq511bGQVA-4oMjQq_KP6TUsUv+Jg@mail.gmail.com>
From: "cb.list6" <cb.list6@gmail.com>
To: Simon Perreault <simon.perreault@viagenie.ca>
Content-Type: multipart/alternative; boundary=001a11c244926b1bd404e00f0340
Cc: behave@ietf.org, ivan@cacaoweb.org
Subject: Re: [BEHAVE] (no subject)
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jun 2013 13:56:54 -0000

On Jun 26, 2013 1:11 AM, "Simon Perreault" <simon.perreault@viagenie.ca>
wrote:
>
> Le 2013-06-25 18:46, ivan c a écrit :
>
>> We have, for all UDP communications and all outbound TCP sessions:
>> - one socket is bound to one local endpoint on the host. Additionally,
two
>> sockets have to bind to two different local endpoints.
>
>
> Not true. If you call connect() on a UDP socket, it behaves just like a
TCP socket.
>
>
>> - one internal endpoint (=local endpoint) is mapped to one external
>> endpoint on the NAT
>> As a result, if no overloading, the NAT has to allocate a new external
>> endpoint for every outbound TCP session.
>> This doesn't apply to UDP.
>
>
> Not true because of the above.
>
>
>>>> Back to NAT port overloading. A collision occurs when 2 sessions share
>>>> the
>>>> same 5-tuple.
>>>
>>>
>>> Stop right here. Some NATs don't track sessions. Those NATs don't care
>>> about 5-tuples. All they do is map internal 3-tuple to external 3-tuple.
>>
>>
>>> So for those NATs there is no conflict. They will just translate the
>>> packets according to the existing mapping.
>>>
>>> All the following doesn't make sense to me given this.
>>>
>>
>> Sure, *stateless* NATs also can't do much endpoint dependent filtering
and
>> lots of other
>> things. They certainly can't do port overloading and are out of scope of
>> this discussion.
>
>
> I'm not referring to stateless NATs. I'm referring to stateful NATs that
only map internal 3-tuple to external 3-tuple and do not do anything with
5-tuples.
>
>
>> Nevertheless, NATs that do look at the full 5-tuple are free to implement
>> port overloading if they wish.
>
>
> I still haven't seen any explanation why the following excerpts do not
apply.
>
> RFC 4787:
>
>    REQ-3:  A NAT MUST NOT have a "Port assignment" behavior of "Port
>       overloading".
>
>    Justification:  This requirement must be met in order to enable two
>       applications on the internal side of the NAT both to use the same
>       port to try to communicate with the same destination.  NATs that
>       implement port preservation have to deal with conflicts on ports,
>       and the multiple code paths this introduces often result in
>       nondeterministic behavior.  However, it should be understood that
>       when a port is randomly assigned, it may just randomly happen to
>       be assigned the same port.  Applications must, therefore, be able
>       to deal with both port preservation and no port preservation.
>
> RFC 5382:
>
>
>    REQ-7:  A NAT MUST NOT have a "Port assignment" behavior of "Port
>       overloading" for TCP.
>
>    Justification:  This requirement allows two applications on the
>       internal side of the NAT to consistently communicate with the same
>       destination.
>
> Simon
>
>

i have the port overloading feature and plan to use it.

Furthermore, i run a substantial endpoint dependent cgn. P2p on ipv4 is
dead, has been dead.

CB _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave