Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation

Nejc Škoberne <nejc@skoberne.net> Tue, 16 August 2011 12:00 UTC

Return-Path: <nejc@skoberne.net>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E58C21F8ABD for <softwires@ietfa.amsl.com>; Tue, 16 Aug 2011 05:00:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.155
X-Spam-Level:
X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 uQvyd6qgfc8e for <softwires@ietfa.amsl.com>; Tue, 16 Aug 2011 05:00:01 -0700 (PDT)
Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by ietfa.amsl.com (Postfix) with ESMTP id 19DCC21F8A55 for <softwires@ietf.org>; Tue, 16 Aug 2011 05:00:00 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tnode.com (Postfix) with ESMTP id 860A622780EE; Tue, 16 Aug 2011 14:00:47 +0200 (CEST)
Received: from mail.tnode.com ([127.0.0.1]) by localhost (mail.tnode.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6g5FM8KNTjS; Tue, 16 Aug 2011 14:00:44 +0200 (CEST)
Received: from [158.125.103.63] (co-staff-103-063.lut.ac.uk [158.125.103.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id CB24822780D2; Tue, 16 Aug 2011 14:00:43 +0200 (CEST)
Message-ID: <4E4A5BEE.3030708@skoberne.net>
Date: Tue, 16 Aug 2011 13:00:46 +0100
From: Nejc Škoberne <nejc@skoberne.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: mohamed.boucadair@orange-ftgroup.com
References: <4E4A4569.8030706@skoberne.net> <94C682931C08B048B7A8645303FDC9F33E54A62CD2@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F33E54A62CD2@PUEXCB1B.nanterre.francetelecom.fr>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "softwires@ietf.org" <softwires@ietf.org>, "draft-operators-softwire-stateless-4v6-motivation@tools.ietf.org" <draft-operators-softwire-stateless-4v6-motivation@tools.ietf.org>
Subject: Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Aug 2011 12:00:02 -0000

Dear Med,

> [NS: If we consider a "stateful A+P" solution, we don't necessarily
> have a dependency between an IPv6 prefix and IPv4 address. Also, we
> don't have any user-session state in the Service Provider's network.
> 
> Med: Fully agree. FWIW, this is what we called "Binding Table A+P Mode" in http://tools.ietf.org/html/draft-ymbk-aplusp-10#section-4.4.

This is exactly what I had in mind.

> We do, however, have some user state (in order to do stateful tunneling,
> for example). Maybe this is included in "user-session" in your
> terminology, but then I think it would be appropriate to define the
> term "user-session" clearly.]
> 
> Med: We assumed the definition of state as mentioned in RFC1958; but I agree the terminology should be much more clearer.

Yes, "state" is implicitly defined there, however "user-session" is not
defined anywhere.

> [NS: I don't think this is true only for stateless
> solutions. If we have a stateful solution with static port allocation
> (as you mention in section 3.1.3), then implementing such an implicit
> host identification which uses also port information, is doable as
> well.]
> 
> Med: I Agree. But then you loose other benefits of the stateful: have an aggressive address sharing ratio.

You indeed loose agressive sharnig ratio, but you have somewhat more
flexible addressing. Also, the CPEs can be then really simple devices,
excluding any of the NAPT functionality, doing only stateless encapsulation.
However, what you loose/gain is irrelevant for my point. I think this
section should be modified in a way like the logging section or any
other appropriate way, which explains, that this is not the benefit of
the stateless nature, but rather the benefit of the static port allocation.

Thanks,
Nejc