Re: [Softwires] 4rd-U complement - e2e transparency to IPv4 TOS

Ole Troan <otroan@employees.org> Tue, 18 October 2011 07:42 UTC

Return-Path: <ichiroumakino@gmail.com>
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 DEA2721F8B45 for <softwires@ietfa.amsl.com>; Tue, 18 Oct 2011 00:42:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.329
X-Spam-Level:
X-Spam-Status: No, score=-3.329 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 JvWB3fy02ATP for <softwires@ietfa.amsl.com>; Tue, 18 Oct 2011 00:42:46 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C3E3121F86FF for <softwires@ietf.org>; Tue, 18 Oct 2011 00:42:45 -0700 (PDT)
Received: by wwe6 with SMTP id 6so267164wwe.13 for <softwires@ietf.org>; Tue, 18 Oct 2011 00:42:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=WLpQwzbynqjkEmnDddH3cfd3Kbbe9/X9idDcxbMcFfw=; b=u6yjzevWfD4Cqwd1iuNytbrHTHv6xrx47/PS3IQuNK2XJXMjAM4pWSlNrqs7zwymwY wO1YtjeXXjRtAK4zvGwVAwJsxqB/7XpcKlyxvK8+Zzk9epueChTHnOSC5lO2dCZ36sql QJNlTn07fvRUDNmSAMzrWAw4NpRD/n6HvveaQ=
Received: by 10.227.55.5 with SMTP id s5mr428613wbg.92.1318923763656; Tue, 18 Oct 2011 00:42:43 -0700 (PDT)
Received: from dhcp-osl-vl300-64-103-53-235.cisco.com (dhcp-osl-vl300-64-103-53-235.cisco.com. [64.103.53.235]) by mx.google.com with ESMTPS id ek13sm1913491wbb.3.2011.10.18.00.42.42 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Oct 2011 00:42:42 -0700 (PDT)
Sender: Ole Troan <ichiroumakino@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Ole Troan <otroan@employees.org>
In-Reply-To: <BF86D754-BF12-4F44-A9DD-93112B0B38DF@laposte.net>
Date: Tue, 18 Oct 2011 09:42:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C036D7AF-9005-4032-AE74-52D5B62570C6@employees.org>
References: <85015B23-C124-43DB-913D-3829B895C2A9@laposte.net> <83A72484-7A54-4A30-AF9B-5FC9D97A9E14@gmail.com> <CAFUBMqWrw8e7sO80U74Q+UvJwW_sqxZZnnwTo7jhyayFBn5_Mg@mail.gmail.com> <6668E2F8-EEBA-4AF3-8110-2B0B43D3BC3E@gmail.com> <CAFUBMqVbZ7uTvHRpQDV1Y1eN9hJZ2tofzNvAM0hFHCrWZ_mA6g@mail.gmail.com> <596276A4-1C63-4A92-90FA-BC958DFB2053@gmail.com> <C7601B91-24ED-4C7F-A771-10F6AFE93F2F@laposte.net> <9D55CDB2-0DE1-441B-A622-22C3E2C66D4E@employees.org> <87BE3426-9B03-4D3E-AFBF-AB12923D2D84@laposte.net> <542B93F7-F8E1-4E2B-BEB9-CF8196BAAB45@employees.org> <C0590740-D4FC-4BF7-8AD6-BB77E2668479@laposte.net> <3D30CA78-9268-4CAB-AADE-7DD9E30DE6D8@employees.org> <BF86D754-BF12-4F44-A9DD-93112B0B38DF@laposte.net>
To: Rémi Després <despres.remi@laposte.net>
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] 4rd-U complement - e2e transparency to IPv4 TOS
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, 18 Oct 2011 07:42:47 -0000

Remi,

> Let me now ask whether you challenge any of the following:
> a) One standard is better than two.
> b) Maintaining network transparency to IPv4 packets is a useful feature
> c) Being able to apply IPv6 O&M tools to IPv4 traffic, e.g. with ACLs, is a useful feature

I think we need to detail this point more:

c1) apply IPv6 features on the traffic as if it is IPv6. use of 5 tuple etc.
c2) apply IPv4 features on the traffic as if it is IPv4.
c3) be able to redirect traffic or communicate with native IPv6 only hosts. e.g. web cache, web authentication

if this is useful or not, depends on your world view...
traditionally the whole purpose of a tunnel was to bypass devices in the middle mingling with your packets.

_iff_ one wishes that a "legacy" router in the middle of the traffic path should be able to apply features and classifiers
based on 5 tuple, then translation supports c1 and c3.
encapsulation supports none.
what I hear on the list is that one don't want to treat this as IPv6 traffic, but want to be able to identify it as IPv4 traffic. and presumably apply IPv4 features and classifiers on that traffic. if that's the case, you need to modify the box in the middle anyway, and I would claim it is a lot easier to move a pointer 40 bytes, than to recreate the IPv4 header on the fly.

> d) Encapsulation has b) but not c)
> e) Double translation has c) but not b)
> f) 4rd-U has both b) and c)

I disagree. double translation has just as much of b) as 4rd-U has. but I will claim that double translation offers less
transparency than encapsulation.

> - If you challenge one or several of these, our debate can continue on well identified subjects.
> - If you don't challenge any of a) to f), we are IMHO on the right track to make progress.
> 
> Please do answer these questions so that questions you ask me can be answered in a clarified context.

in my view this doesn't change the encapsulation versus translation debate.
would an option be to merge your ideas with the new dIVI-pd document that will reference the new mapping document?

cheers,
Ole