Re: [Softwires] Objection to 4rd-U made in Softwire meeting understood to be invalid

Ole Troan <> Wed, 16 November 2011 02:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB4DE1F0CA4 for <>; Tue, 15 Nov 2011 18:43:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.524
X-Spam-Status: No, score=-9.524 tagged_above=-999 required=5 tests=[AWL=0.775, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E4ZeGkMpCHSw for <>; Tue, 15 Nov 2011 18:43:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 56EE71F0C9E for <>; Tue, 15 Nov 2011 18:43:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2383; q=dns/txt; s=iport; t=1321411394; x=1322620994; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=D5QLwqDRsK5CWIzQ3Y+ppcp8/1PpswWsq3FB3ju2ONg=; b=i/xb7W+2+GrDeD5kkJPum/o2GsFuUr5FyjKpigGLThcpWA6Nl3+1Usv0 fvL28A/9rrIiOVzvuj1Cc8tFiaWejL1b77FOu0jpUWWOHy33E4B+KlAhm +IniuNJ+k3knvRRNYBAOYzDzpzgsf791qaYVjgDo+duvp+xDjDZngZuRi A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EALsiw06Q/khN/2dsb2JhbABDqXKBBYFyAQEBAwESASc/BQsLRlcGLgeHYJpUAZ5YiTRjBIgSjCKSCQ
X-IronPort-AV: E=Sophos;i="4.69,518,1315180800"; d="scan'208";a="121713607"
Received: from ([]) by with ESMTP; 16 Nov 2011 02:43:13 +0000
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id pAG2h9jB008048; Wed, 16 Nov 2011 02:43:11 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Ole Troan <>
In-Reply-To: <>
Date: Wed, 16 Nov 2011 10:26:19 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Rémi Després <>
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG <>
Subject: Re: [Softwires] Objection to 4rd-U made in Softwire meeting understood to be invalid
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: Wed, 16 Nov 2011 02:43:18 -0000

Remi, et al,

> In the Softwire meeting of Monday, the key argument against the 4rd unified approach (4rd-U) was that *Because checksum neutrality of addresses is part of 4rd-U, it would allegedly cause "address spreading" (addresses used between a pair of hosts would vary)*. 
> You had a slide asserting it, and the argument was taken as granted, and important, in verbal comments from Mark Townsley and Dave Thaler.
> I forcefully declared that this was technically false.
> Since no time has been granted to explain, I invited anyone in doubt to contact me for explanations. 
> Thanks for having taken the time to do it.
> Following our discussion of yesterday, I think you now understand that, as I said:
> - *TCP/UDP checksum neutrality of addresses DOES NOT interfere in any way with stability of addresses between host pairs*.

acknowledged. as far as I can understand the checksum neutrality proposal will work, and it will result in stable addresses.
two flows between two hosts will have the same addresses. and there is no "destination spread" with this mechanism.

apologies for the uncertainty and confusion created by questioning this.

> - Consequently, the key argument of the meeting against 4rd-U is invalid.

that I disagree with. there were multiple arguments. let me try to summarize.

- if 4rd-U resulted in one specification as opposed to two then 4rd-U is a good thing.
  if 4rd-U results in three specifications as opposed to two, then that is a bad thing.
  I have discussed this with the authors of the other two proposals, and they don't appear to withdraw their proposals
  in favour of this one.
- 4rd-U has destination spread as written with the Max PSID has destination spread. this can obviously be fixed.
- 4rd-U has the V octet, which impacts native IPv6 forwarding, and I think in general is problematic
- 4rd-U is 'just' another translation proposal; it might provide a 'better' translation than what has been done so far
  in behave, but that doesn't alleviate the arguments made for encapsulation
- 4rd-U has checksum neutrality, there is already a solution for the checksum. that is widely implemented, why
  bring in another way of doing it, creating two specifications for the same problem instead of using an existing one?