Re: [Softwires] Unified proposal for stateless IPv4 Residual Deployments (4rd-U) - Contributors?

Rémi Després <> Tue, 29 November 2011 18:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3CD8811E80BD for <>; Tue, 29 Nov 2011 10:11:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.205
X-Spam-Status: No, score=-1.205 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aEggdh2Jx5Tc for <>; Tue, 29 Nov 2011 10:11:37 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 65EDE21F8BEC for <>; Tue, 29 Nov 2011 10:11:37 -0800 (PST)
Received: from (localhost []) by (SMTP Server) with ESMTP id 48178700023F; Tue, 29 Nov 2011 19:11:36 +0100 (CET)
Received: from [] ( []) by (SMTP Server) with ESMTP id E1AB170001FD; Tue, 29 Nov 2011 19:11:35 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Rémi Després <>
In-Reply-To: <>
Date: Tue, 29 Nov 2011 19:11:35 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Ole Troan <>
X-Mailer: Apple Mail (2.1084)
X-sfr-mailing: LEGIT
Cc: Softwires WG <>
Subject: Re: [Softwires] Unified proposal for stateless IPv4 Residual Deployments (4rd-U) - Contributors?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Nov 2011 18:11:38 -0000

Le 29 nov. 2011 à 17:15, Ole Troan a écrit :

> Remi,
>> For those who attended the Softwire session in Taipei, please note that the serious objection against 4rd-U expressed by several participants during the meeting has been, soon after, acknowledged to be invalid (
>> Also, other (less important) objections have been answered in, without reaction so far. 
> I do not think that's a fair representation.

It was intended to be one, and is still believed to be so (see below)

> the main objection to 4rd-u is that it is 'just another translation' solution.

That's not what I heard during the meeting.
Both Mark Townsley and Dave Thaler, taking for granted your statement that checksum-neutral addresses of 4rd-U would cause "address spray", said firmly that 4rd-U should be rejected because it wouldn't work.

In my understanding, not working is a show stopper, which I call a "main objection".

b) If your main objection is that 4rd-U would be 'just another translation', it is ALSO invalid. 
If you have read my answer to your list of objections, you should know that 4rd-U is a reversible-header-mapping solution, and as such is based on neither translation nor encapsulation. (actually a tunnel closer to encapsulation in my understanding).

> how many do we need?

Many consider that, if there is the choice, ONE standard is better than several.

The point is that 4rd-U combines advantages of double translation and encapsulation with only a slightly different tradeoff between optimizations of header-length and processing time.

Doubts are legitimate as long as the specification is incomplete, but that's why more work is needed.

> it doesn't appear to offer any benefits compared to the already specified solution.

Which solution? (So far, there are two in the pipe - translation and encapsulation.)
Meeting requirements of both solutions is AFAIK a benefit.

> as it stands it will just result in 3 ways of doing the same thing, instead of 2.

Different view on this.
Three standards would make no sense.

> the topic discussed in softwires, wasn't the main objection. as far as I can see, "checksum neutrality" does not offer any advantages over incrementally updating the L4 checksum.

Again, commenting my previous answer to your list of objections would be be more constructive than repeating that 4rd-U doesn't do anything without arguing on substance.

Since there is no obligation to comment, please refrain from criticizing a solution without commenting previous answers made for you.

> every node doing this will have to look into the L4 header anyway.

Sure. IPv4 address sharing implies _looking_ at port fields (true also for encapsulation).

But this doesn't imply that L4 data need to be  modified, especially if these modifications need to depend on whether the protocol is TCP UDP, DCCP, etc. 
Encapsulation and reversible header mapping don't care about this, which is one of their virtues.