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

Mark Townsley <mark@townsley.net> Tue, 18 October 2011 09:11 UTC

Return-Path: <mark@townsley.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 E46CF21F8783 for <softwires@ietfa.amsl.com>; Tue, 18 Oct 2011 02:11:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.498
X-Spam-Level:
X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 8oUFA3BeS6iu for <softwires@ietfa.amsl.com>; Tue, 18 Oct 2011 02:11:51 -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 AA29521F86A4 for <softwires@ietf.org>; Tue, 18 Oct 2011 02:11:47 -0700 (PDT)
Received: by wwe6 with SMTP id 6so343156wwe.13 for <softwires@ietf.org>; Tue, 18 Oct 2011 02:11:47 -0700 (PDT)
Received: by 10.227.26.10 with SMTP id b10mr582873wbc.22.1318929106754; Tue, 18 Oct 2011 02:11:46 -0700 (PDT)
Received: from ams-townsley-8716.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fi11sm2312584wbb.9.2011.10.18.02.11.44 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Oct 2011 02:11:45 -0700 (PDT)
From: Mark Townsley <mark@townsley.net>
Content-Type: multipart/alternative; boundary="Apple-Mail-53--827996734"
Date: Tue, 18 Oct 2011 11:11:43 +0200
References: <C653042D-9AC3-4F2D-9F23-4061A1DD4377@townsley.net>
To: Softwires WG <softwires@ietf.org>
Message-Id: <1BF1A854-AB42-4756-BC5B-86720C57AFBD@townsley.net>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
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 09:11:52 -0000

(resending as this was bounced from softwires due to the message being too long - I removed the thread cc'd at the end)

Begin forwarded message:

> From: Mark Townsley <mark@townsley.net>
> Date: October 18, 2011 11:07:34 AM GMT+02:00
> To: Rémi Després <despres.remi@laposte.net>
> Cc: sarikaya@ieee.org, Softwires WG <softwires@ietf.org>
> Subject: Re: [Softwires] 4rd-U complement - e2e transparency to IPv4 TOS
> 
> 
> On Oct 18, 2011, at 10:38 AM, Rémi Després wrote:
> 
>> 
>> Le 18 oct. 2011 à 10:21, Mark Townsley a écrit :
>> 
>>> 
>>> While it is interesting to explore the various design spaces, we do not need more ways to munge an IPv4 packet into an IPv6 packet and back to an IPv4 packet. Any alternative beyond the simple and obvious encap/decap that routers have used for decades is already too much IMHO, we certainly don't need a 3rd or 4th method.
>> 
>>> Let's please curtail new the inventions, and get back to the standardization.
>> 
>> Sorry that you see it that way.
>> 
>> The interim meeting has been useful in that objectives of present parties were clarified better than ever before.
>> Standardization is, and has always been, a process in which understanding each other, and finding ways to accommodate all valid concerns, are been key to success.
>> That's what I have been working for: good standardization. 
>> 
>> Would you please indicate what you personally challenge in this:
>> a) One standard is better than two.
> 
> Yes. 
> 
>> 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
>> d) Encapsulation has b) but not c)
>> e) Double translation has c) but not b)
>> f) 4rd-U has both b) and c)
> 
> IPv6 packets with incorrect checksums may be incompatible with firewalls, website redirects (e.g. I don't see why the web server will not just drop the packet if the checksum fails), etc. 
> 
> The translation (or header mapping) cases all purport to be helpful to various processing or operations along the path between the router endpoints. By definition, it is more complicated to weigh relative value of the various options in this space as we have to start weaving our way through sometimes unknown and certainly non-standard DPI, ACL, redirection, O&M, etc. features at multiple places in the network. In some cases, I'm afraid that we are optimizing based on speculative properties of IPv6 networks that are still in their infancy in terms of mainstream deployment. Experience tells me convergence here will be difficult, and getting it right will be even more difficult. 
> 
> I think we need to get the base case of stateless encap/decap out the door so that it can be built into CPE alongside the stateful ds-lite encap/decap option that is being built already. Then we can continue in the search for the best translation method (which, if we are still coming up with new clever alternatives right now, we are not converging nearly as fast as we might think we are).
> 
> - Mark