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

Maoke <fibrib@gmail.com> Mon, 30 January 2012 10:47 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 5FBD321F8670 for <softwires@ietfa.amsl.com>; Mon, 30 Jan 2012 02:47:50 -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 vIRQY91chjzd for <softwires@ietfa.amsl.com>; Mon, 30 Jan 2012 02:47:49 -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 290FD21F8636 for <softwires@ietf.org>; Mon, 30 Jan 2012 02:47:49 -0800 (PST)
Received: by qcsf16 with SMTP id f16so2469277qcs.31 for <softwires@ietf.org>; Mon, 30 Jan 2012 02:47:48 -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=OypXENAWHFNy6lQ360laaygTEXpTxNanSjjsqGIDY5Y=; b=B4AzrtEQQ4+SWMaf8n5MvDMpUZzbJrZ6b4tP6eAb0mQ1Hd229MY2Y9Ztnl2VkcnVD+ mKiUx18W1K1bPGTlaOez44fg34Zn1tgR64lfCra7qSiMRalR7KzS4zDmujY2dgtmoTE1 pZow+vYRSD1r7Ij5gTcE5F31nx73BihkHHEX8=
MIME-Version: 1.0
Received: by 10.229.102.155 with SMTP id g27mr6159075qco.103.1327920468586; Mon, 30 Jan 2012 02:47:48 -0800 (PST)
Received: by 10.229.211.72 with HTTP; Mon, 30 Jan 2012 02:47:48 -0800 (PST)
In-Reply-To: <52DBFDA9-1BBB-47DD-9165-F9C0341A669C@laposte.net>
References: <C992D2F8-5E8C-4601-B07D-37AB2B7E72D3@laposte.net> <CAFUBMqXm3BiK5Cq8nmy97Nr6eVYZgooc38Rv3PB6nOWAzmMbUg@mail.gmail.com> <52DBFDA9-1BBB-47DD-9165-F9C0341A669C@laposte.net>
Date: Mon, 30 Jan 2012 19:47:48 +0900
Message-ID: <CAFUBMqXVx9F5V+_5RcLdr8V5dn9Hxixm+19hXX10Zh-86t-W4w@mail.gmail.com>
From: Maoke <fibrib@gmail.com>
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= <despres.remi@laposte.net>
Content-Type: multipart/alternative; boundary=0023544706d8d1eff004b7bc93c4
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 10:47:50 -0000

2012/1/30 Rémi Després <despres.remi@laposte.net>

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

well, if address spaces (as well as routings) are totally disjoint, it is
hard to call it as "coexist", ;-) and definitely there is no compatibility
to single translation in RFC6145 at all. as the result, RFC6145 provides a
unified solution, while 4rd-U requires ISP (who prefer to use
translation) disjointly deploy their networks for single and double
translations.


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

the attack preventing should be done everywhere, including in the middle of
the IPv6 domain. however, IPv6-containing-ICMPv4 loses information checksum
regarding the original IPv4 addresses and therefore (no matter how the
firewall is upgraded) the consistency check is not possible. it should be a
big security concern.

this is one of the major reasons that i don't think putting ICMPv4 into
IPv6 directly is a good idea. either full encapsulation or Simple IP/ICMP
translation is far better.

best,
maoke


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