Re: [v4tov6transition] [Softwires] 6a44 MTU issues

Rémi Després <> Wed, 13 October 2010 15:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 338323A6B98; Wed, 13 Oct 2010 08:42:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.425
X-Spam-Status: No, score=-1.425 tagged_above=-999 required=5 tests=[AWL=0.524, 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 JcjaC46TD4ln; Wed, 13 Oct 2010 08:42:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5E2DE3A6B95; Wed, 13 Oct 2010 08:42:19 -0700 (PDT)
Received: from (localhost []) by (SMTP Server) with ESMTP id 0378E700009E; Wed, 13 Oct 2010 17:43:27 +0200 (CEST)
Received: from [] ( []) by (SMTP Server) with ESMTP id 8CC177000098; Wed, 13 Oct 2010 17:43:26 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <>
In-Reply-To: <>
Date: Wed, 13 Oct 2010 17:43:26 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <><E1829B60731D1740BB7A0><E1829B60731D1740BB7A062><AANLkTik0_9CRSfi_O53MChgt><D8BB9123-C611-4476-AFA1-D0ADEEDB6270@f><E1829B60731D1740BB7A0626B4FAF0A65C59B797F3@XCH-NW-01V.nw.nos.boeing .com><><E1829B60731D1740BB7A062><> <> <>
To: "Templin, Fred L" <>
X-Mailer: Apple Mail (2.1081)
Cc: Softwires <>, "" <>
Subject: Re: [v4tov6transition] [Softwires] 6a44 MTU issues
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Oct 2010 15:42:27 -0000

Le 13 oct. 2010 à 17:17, Templin, Fred L a écrit :

> Hi Remi, 
>> -----Original Message-----
>> From: 
>> [] On Behalf Of Rémi Després
>> Sent: Tuesday, October 12, 2010 12:26 AM
>> To: Templin, Fred L; Washam Fan
>> Cc: Softwires;
>> Subject: Re: [Softwires] [v4tov6transition] 6a44 MTU issues
>> Fred and Washam,
>> I reacted too fast to previous remarks when I proposed to 
>> modify the accepted IPv6 MTU in 6a44 draft.
>> If IPv6 packets longer than 1280 would be accepted by 6a44 
>> servers, hosts could receive them in fragmented IPv4 datagrams.
> Or they might be reassembled in the NAT(s) in front of
> the host.
They would indeed.
But they would then be forwarded across the customer network.
There, they may somewhere be fragmented to fit into fragments shorter than the ISP MTU + 28.
This happens for example if the ISP IPv6 MTU would be 1500-28 and that of some link in the customer site would be 1500-40 (say, for an IPv4 in IPv6 tunnel). 

>> This would be contrary to the objective of simplicity 
>> (datagram reassembly would have to be include in 6a44 
>> clients) and to the objective of security (a new door would 
>> be open to dos attacks).
>> No change on this point will therefore appear in the next 
>> version of the draft. 
>> Some additional explanations may be appropriate, but 
>> preferably after a consensus on what has to be said.
>> Then the MTU issue of IPv6 in IPv6 tunnels that Fred 
>> underlines remains as is.
> Right.
>> If the PMTU of such a tunnel is unknown, or known to be less 
>> than 1280+40,
> Actually, 1280+40+IPsec headers and trailers in the case
> of VPN.

I was only discussing the direct IPv6 in IPv6 case.
But, yes, it is in general 1280 + the encapsulation header, whatever its size.

>> tunnel endpoints have to tunnel 1280-octets 
>> external packets in two pieces, using a fragmented IPv6 
>> datagram for this.
> OK, so steady-state IPv6 fragmentation and reassembly between
> VPN tunnel endpoints is expected as normal operation in this
> model.

(A consequence of privileging connectivity and stateless operation).

>> Reassembly at the other end is then necessary. 
>> It can be facilitated if the tunnel is treated as only one 
>> flow,
> Can you say more about what you mean by this?

I mean that, because packets are almost always kept in sequence for a flow (otherwise TCP efficiency would be in general very poor) reassembly can be limited to consecutive fragments of only one datagram (the one being currently reassembled).
A packet permutation that interleaves fragments of two different datagrams leads in this case to a loss (but with low enough a frequency for it to be acceptable). 
This is significantly simpler than in the case where fragments of many datagrams my be interleaved.
>> with packets in general kept in sequential order.
> In-order delivery is not a strict requirement for
> correct IPv6 reassembly - but the fact that steady-state
> IPv6 frag/reass is required seems onerous.

See just above.