Re: [Softwires] Unifying Double Translation and Encapsulation for 4rd (4rd-U)
Maoke <fibrib@gmail.com> Mon, 17 October 2011 05:27 UTC
Return-Path: <fibrib@gmail.com>
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 595AC21F8B22 for <softwires@ietfa.amsl.com>; Sun, 16 Oct 2011 22:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.99
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exDdEWHdlknj for <softwires@ietfa.amsl.com>; Sun, 16 Oct 2011 22:27:12 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8461621F8B24 for <softwires@ietf.org>; Sun, 16 Oct 2011 22:27:12 -0700 (PDT)
Received: by qyk34 with SMTP id 34so603106qyk.10 for <softwires@ietf.org>; Sun, 16 Oct 2011 22:27:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.229.80.16 with SMTP id r16mr3781774qck.107.1318829230093; Sun, 16 Oct 2011 22:27:10 -0700 (PDT)
Received: by 10.229.214.212 with HTTP; Sun, 16 Oct 2011 22:27:10 -0700 (PDT)
In-Reply-To: <187B1ACE-8FB8-4C8C-8130-03DCF10772CF@laposte.net>
References: <187B1ACE-8FB8-4C8C-8130-03DCF10772CF@laposte.net>
Date: Mon, 17 Oct 2011 14:27:10 +0900
Message-ID: <CAFUBMqXoEGd5RA4zwuZBboZ0C=BGXio9LOAS=bjG2PHTuU++1w@mail.gmail.com>
From: Maoke <fibrib@gmail.com>
To: Rémi Després <despres.remi@laposte.net>
Content-Type: multipart/alternative; boundary="0016364ee764c77aa704af77db02"
Cc: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] Unifying Double Translation and Encapsulation for 4rd (4rd-U)
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: 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? thanks, maoke 2011/10/12 Rémi Després <despres.remi@laposte.net> > Hello all, > > The following draft has just been posted: > tools.ietf.org/html/draft-despres-softwire-4rd-u-00. > > Hope it will be useful for your continuing work on stateless solutions in > Softwire. > > Clarification questions are most welcome. > > Regards, > RD > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >
- [Softwires] Unifying Double Translation and Encap… Rémi Després
- Re: [Softwires] Unifying Double Translation and E… Behcet Sarikaya
- Re: [Softwires] Unifying Double Translation and E… Jacni Qin
- Re: [Softwires] Unifying Double Translation and E… Satoru Matsushima
- Re: [Softwires] Unifying Double Translation and E… Jacni Qin
- Re: [Softwires] Unifying Double Translation and E… Maoke