Re: [Softwires] Unifying Double Translation and Encapsulation for 4rd (4rd-U)

Maoke <> Mon, 17 October 2011 05:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 595AC21F8B22 for <>; Sun, 16 Oct 2011 22:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.99
X-Spam-Status: No, score=-2.99 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id exDdEWHdlknj for <>; Sun, 16 Oct 2011 22:27:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8461621F8B24 for <>; Sun, 16 Oct 2011 22:27:12 -0700 (PDT)
Received: by qyk34 with SMTP id 34so603106qyk.10 for <>; Sun, 16 Oct 2011 22:27:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3gvPlXbEeu28DmV46KR64oTkjarDVxORnDmUVfpchYg=; b=v4RL0VUa1KyHUqAGN2XrIlBPgkM7I2QQe6mixi64a4fPYBJpJIw2LsyLUH9HKNIhLN V7W11jkrt2jtMn76zAQ1VRfkA7Drm34gYMEDXuJeqqkMczqJWmdet+f2gEFjWt1rJMZn 4xFbTDNyOUUk5/gc1odeT+GcefJ9lR6D7XkLk=
MIME-Version: 1.0
Received: by with SMTP id r16mr3781774qck.107.1318829230093; Sun, 16 Oct 2011 22:27:10 -0700 (PDT)
Received: by with HTTP; Sun, 16 Oct 2011 22:27:10 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Mon, 17 Oct 2011 14:27:10 +0900
Message-ID: <>
From: Maoke <>
To: Rémi Després <>
Content-Type: multipart/alternative; boundary="0016364ee764c77aa704af77db02"
Cc: Softwires WG <>
Subject: Re: [Softwires] Unifying Double Translation and Encapsulation for 4rd (4rd-U)
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: Mon, 17 Oct 2011 05:27:13 -0000

hi Remi,

i would like to follow your idea of keeping end-to-end transparency of DF
bit in double translation.

1. keeping DF transparency might be really significant

we noticed that the fragment in IPv4 is rare but it doesn't mean the DF is
fairly useless. in contrast, today's IPv4 has very small percentage of
fragment just because we are favored by the DF bit and the path MTU
discovery functionality based on it. if we observe the percentage of DF=1
and DF=0 packets, we would see DF is not trivial. forcing DF = 0 at the
boundary from IPv6 to IPv4 may disable the PMTU discovery in the destination
IPv4 domain; forcing DF = 1, though, may bring worse performance for the
applications that do not care of being fragmented but wouldn't like to be
dropped due to packet-too-big.

2. define a reserved bit in IPv6 fragment header for the DF bit of the
IPv4-translated packets

putting is the DF and IPv4 identifier into the fragment header is a good
idea. however, considering the double translation is a case of translation.
it is possible that a src host with an IPv4-translatable IPv6 address
generates a fragment header with a 32-bit identifier happening to have the
first 16 bit as either 0x8000 or 0x0000, making a fake D bit in your current
proposal. i'd prefer to use one of the reserved bits in the fragment header
for the DF.

how do you and others think?


2011/10/12 Rémi Després <>

> Hello all,
> The following draft has just been posted:
> Hope it will be useful for your continuing work on stateless solutions in
> Softwire.
> Clarification questions are most welcome.
> Regards,
> RD
> _______________________________________________
> Softwires mailing list