Re: [Softwires] New version of 4rd-U - with plain Encapsulation as a variant

Maoke <fibrib@gmail.com> Sun, 29 January 2012 04:38 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 9112121F84B4 for <softwires@ietfa.amsl.com>; Sat, 28 Jan 2012 20:38:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.298
X-Spam-Level:
X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[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 kHEaPnOTd-2G for <softwires@ietfa.amsl.com>; Sat, 28 Jan 2012 20:38:09 -0800 (PST)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7201A21F84A5 for <softwires@ietf.org>; Sat, 28 Jan 2012 20:38:09 -0800 (PST)
Received: by qcsf16 with SMTP id f16so1922392qcs.31 for <softwires@ietf.org>; Sat, 28 Jan 2012 20:38:09 -0800 (PST)
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=ek4DXRAowpp7VyolbPAszt3xDYnudi5P1zrW2odeHfE=; b=T562oVmG6qY8HuNry93doEPp5DNKqgjf/INfqTz33DskygIoKQmDpvIWqVSGl3svwK KfT53Opn0sWS5f4zdxiC8wMnpNgJALb4TrlUuyIrdQji0Mi8nf1XgSrT/UN0xNyQfNGW H8/xItr2Iq4F3lbHZGVERGdV42LRG96go25Kw=
MIME-Version: 1.0
Received: by 10.224.202.65 with SMTP id fd1mr15704086qab.12.1327811887928; Sat, 28 Jan 2012 20:38:07 -0800 (PST)
Received: by 10.229.211.72 with HTTP; Sat, 28 Jan 2012 20:38:07 -0800 (PST)
In-Reply-To: <C992D2F8-5E8C-4601-B07D-37AB2B7E72D3@laposte.net>
References: <C992D2F8-5E8C-4601-B07D-37AB2B7E72D3@laposte.net>
Date: Sun, 29 Jan 2012 13:38:07 +0900
Message-ID: <CAFUBMqXm3BiK5Cq8nmy97Nr6eVYZgooc38Rv3PB6nOWAzmMbUg@mail.gmail.com>
From: Maoke <fibrib@gmail.com>
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= <despres.remi@laposte.net>
Content-Type: multipart/alternative; boundary=20cf30050eeae895c304b7a34b34
Cc: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] New version of 4rd-U - with plain Encapsulation as a variant
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: Sun, 29 Jan 2012 04:38:10 -0000

hi Remi,

it a little confuses me that the new version introduces 2 variants - what
is the technical difference of 4rd-U encapsulation variant vs.
MAP-E? (except written in a single or some separated documents)

on the other hand, it is unfair to state the benefit "Header-mapping
provides more complete transparency to IPv4 packets than solutions using
twice the IPv6/IPv4 translation of RFC6145" without mentioning the (at
least the following two pieces of) cost: 1. losing the compatibility with
single translation; 2. putting ICMPv4 PDU as the payload of IPv6 directly,
with neither IP header nor ICMP header has the address checksum information
- this will disable firewall preventing attacks.

best regards,
maoke
2012/1/29 Rémi Després <despres.remi@laposte.net>

> Hello all,
>
> The new version of the proposed unified 4rd has just ben posted.
> It is available at:
>  http://tools.ietf.org/html/draft-despres-softwire-4rd-u-03
>
> A major evolution since the previous version has been to have in it two
> variants.
> - The Header-mapping variant is as in the previous version
> - The Encapsulation variant is added after comments received, and
> accepted, that some use cases cannot be satisfied if the Header-mapping
> variant is the only one.
>
> Compared to the alternative approach of several MAP documents, the
> single-document approach is expected to avoid duplicate specifications, and
> to facilitate consistency checks of the design.
> Besides:
> - Header-mapping provides more complete transparency to IPv4 packets than
> solutions using twice the IPv6/IPv4 translation of RFC6145.
> - It has also the advantage of a simpler and self-sufficient specification.
> - The algorithm which permits BRs to forward datagram fragments without
> datagram reassembly is included.
> - The problem of fragmented datagrams from shared address CEs that must
> have different Identification if they go to common destinations is covered.
> - The design re-introduces the Domain IPv6 suffix which in some earlier
> 4rd designs, and somehow has been lost.
> - The port-set algorithm is without parameter.
>
> All questions and comments will be most welcome.
>
> Regards,
> RD
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>