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

Rémi Després <despres.remi@laposte.net> Mon, 30 January 2012 09:22 UTC

Return-Path: <despres.remi@laposte.net>
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 A261021F8476 for <softwires@ietfa.amsl.com>; Mon, 30 Jan 2012 01:22:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level:
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
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 gueIu2FzPXMv for <softwires@ietfa.amsl.com>; Mon, 30 Jan 2012 01:22:22 -0800 (PST)
Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.119]) by ietfa.amsl.com (Postfix) with ESMTP id 715BF21F8460 for <softwires@ietf.org>; Mon, 30 Jan 2012 01:22:21 -0800 (PST)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2507.sfr.fr (SMTP Server) with ESMTP id C8A4E7000074; Mon, 30 Jan 2012 10:22:20 +0100 (CET)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2507.sfr.fr (SMTP Server) with ESMTP id 52A5E700006C; Mon, 30 Jan 2012 10:22:20 +0100 (CET)
X-SFR-UUID: 20120130092220338.52A5E700006C@msfrf2507.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-85--431694929
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <despres.remi@laposte.net>
In-Reply-To: <CAFUBMqXm3BiK5Cq8nmy97Nr6eVYZgooc38Rv3PB6nOWAzmMbUg@mail.gmail.com>
Date: Mon, 30 Jan 2012 10:22:19 +0100
Message-Id: <52DBFDA9-1BBB-47DD-9165-F9C0341A669C@laposte.net>
References: <C992D2F8-5E8C-4601-B07D-37AB2B7E72D3@laposte.net> <CAFUBMqXm3BiK5Cq8nmy97Nr6eVYZgooc38Rv3PB6nOWAzmMbUg@mail.gmail.com>
To: Maoke <fibrib@gmail.com>
X-Mailer: Apple Mail (2.1084)
X-sfr-mailing: LEGIT
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: Mon, 30 Jan 2012 09:22:23 -0000

Hi Maoke,

Good to see you back in technical discussions, of which we had so many useful ones.
More in line.

 
Le 2012-01-29 à 05:38, Maoke a écrit :

> 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)

No difference (as said).

>  
> 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.

Not clear AFAIK.
It can be discussed if you expand, but less subjective issues like those below are IMHO more important.

> losing the compatibility with single translation; 2.

I don't see this because, in my understanding:
- IPv6-only CPEs, in order to work with IPv4 shared addresses processed by BRs are stateless, MUST be modified anyway.
- Unmodified IPv6-only CPEs don't need to be modified to work with shared addresses processed by stateful NAT64/DNS64 (with known limitations NAT-related limitations, but this is understood). 
- 4rd-U can coexist with NAT64/DNS64 in ISP networks. (Provided IPv4 address-spaces used by NAT64 and 4rd-U are disjoint, there is AFAIK no operational issue.

If you have a specific configuration that illustrates your concern, it could be discussed with more details.

>  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.


For a site having a customer-provided CPE that integrates a firewall to take advantage of stateless IPv4-address sharing, its FW  MUST be upgraded anyway. Adding to it 4rd-U support is for this a logical solution.  
If the FW-CPE is not modified, its operation across IPv6-only networks remains IPv6-only (translatable to IPv4 by NAT64 if supported by the ISP).
Adding a note on this in the document would be possible, if found useful.  

Cheers,
RD


>  
> 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
>