Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd

Maoke <fibrib@gmail.com> Thu, 15 March 2012 09:02 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 96B1D21F86B8 for <softwires@ietfa.amsl.com>; Thu, 15 Mar 2012 02:02:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.215
X-Spam-Level:
X-Spam-Status: No, score=-3.215 tagged_above=-999 required=5 tests=[AWL=0.083, 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 AgHDxn8TEe+R for <softwires@ietfa.amsl.com>; Thu, 15 Mar 2012 02:02:14 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3B15221F86B6 for <softwires@ietf.org>; Thu, 15 Mar 2012 02:02:14 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so3169207ghb.31 for <softwires@ietf.org>; Thu, 15 Mar 2012 02:02:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DrIMYodsDSQ6lDBl92PlIzb+wzdsw07xBcGkrEiLmAU=; b=XR+XyWAynUURzY60U7wJ5Msr0tYPfVVTMbHHvwNq+yQeERjBtQaa9sXtkomJTBDvMJ 2j9lx+HWNBMXpzM8qTyEFuqfyCRgU8pvsMuou6I6OgdjUn/4va1LDm99596NQusz6Nw+ mRql4ZdWpu5pGMdsCAOYL62/pzYr8g2lOrQP7qV7BIDcZASeeXpQzrVThirt12kLjZFX yYtkAatyG04ESgphoPJGRgEq8FS2RK0f0Lq16iTUhL83Z/TNIGEAZ8BSwXpczStVdO5h EaTxm0Ptz+c9Q8exHfoi9IO2iGo1Ij4EH+g2azRYeSrSQPT4VnG9naAw8CHmTtVaYF8l ljOg==
MIME-Version: 1.0
Received: by 10.229.136.200 with SMTP id s8mr2031481qct.9.1331802133644; Thu, 15 Mar 2012 02:02:13 -0700 (PDT)
Received: by 10.229.98.21 with HTTP; Thu, 15 Mar 2012 02:02:13 -0700 (PDT)
In-Reply-To: <F2C46FAE-30EF-4707-8680-F4CED8A3A7F9@free.fr>
References: <B509CB1C-4A0A-408B-9B4A-C0F847169431@juniper.net> <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <D6428903-FBA0-419C-A37F-A00874F28118@laposte.net> <CAM+vMERsVz7cuC1C52gw12wySaEgw8=44JjS8AUygj0vJ899Cg@mail.gmail.com> <DDD20574-4ECD-4285-BB15-548628FB0425@laposte.net> <CAM+vMETahum9rB+fr=OHAmVobDZSzRRy9mUwkjryhqRvaJWe-Q@mail.gmail.com> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <CAAuHL_D68nkd36ifLzEeVR67Q124VH-pMhM1pkEE_PcLbGxBrw@mail.gmail.com> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <CAFUBMqX9dj8MSeZdJTic5iOT=Jjg4oihWs30FWVAca08v_3=7g@mail.gmail.com> <D476AFD2-3B6B-48A0-971D-C65CC2CFA46B@laposte.net> <CAFUBMqU1wtP5prSaLG8hDSuv-EGWP5Diqoj6WEMHb_q8hNVDdQ@mail.gmail.com> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net> <CAFUBMqVzbtZ7JxunHv7m1zgWjRa2sh7zZS+91aURAy8-xTZW8g@mail.gmail.com> <CAFUBMqXPAA7RjCzgvbuq0WqbKijXwuFebnmrL-zDx_XoZh=Xkg@mail.gmail.com> <FED38071-241D-480C-9A8A-CFA7A55A4F3B@laposte.net> <1A6C1DA5-A352-4BF7-8553-453327902619@laposte.net> <CAFUBMqWv2V2PnZg5iTSuT6Jdbtredzj-4GPuS4VHqpDG+aP4dA@mail.gmail.com> <A4A7C9E3-DBA9-4AA5-A60B-E3D3A187BD7F@laposte.net> <CAFUBMqVT=E=GqBG_-q458GCpYKLk66vuvE-cx81=eTdgyUbj7A@mail.gmail.com> <D1EF9447-336A-48B4-91F4-D514654AC93D@laposte.net> <CAFUBMqWTRb_pjV_VFEDpNof7H+AnOvRM_acQXZ4XRPzAG-865A@mail.gmail.com> <7DED1A34-7237-4F05-B0A4-75C04A09B8E1@laposte.net> <CAFUBMqUVme5Vmm0QuJT4rcZeWo-CZyZoGBkq6RLjO=DRYLKYSg@mail.gmail.com> <AD2E97A4-98FF-4F00-BC28-44AB430870FB@laposte.net> <CAFUBMqXi02DcrTkJ3zjt4fv8EvVJPfAv=CTkM7gesi95jNQSQQ@mail.gmail.com> <8A2DF2DD-C961-4A90-AD62-9C2F647E1A9F@laposte.net> <CAFUBMqXuvBt6DD8JpWt_5+JP33ETqTrz3KbSRm1Kp9ZQBjqs+w@mail.gmail.com> <F2C46FAE-30EF-4707-8680-F4CED8A3A7F9@free.fr>
Date: Thu, 15 Mar 2012 09:02:13 +0000
Message-ID: <CAFUBMqU_ggCiE1Jr=HEAY1a1sunNXQZu1Oi98Jaa7jfd_0puLg@mail.gmail.com>
From: Maoke <fibrib@gmail.com>
To: Rémi Després <remi.despres@free.fr>
Content-Type: multipart/alternative; boundary="002354530350164e9604bb44591d"
Cc: Softwires WG <softwires@ietf.org>, Yong Cui <cuiyong@tsinghua.edu.cn>
Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd
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: Thu, 15 Mar 2012 09:02:15 -0000

2012/3/15 Rémi Després <remi.despres@free.fr>

> Maoke,
>
> Let's try, once more, to understand each other.
>
> If we assume that MAP-T CEs (and BRs) now MUST translate DCCP (which
> is AFAIAC a positive result of our discussion):
> a) Such a CE can communicate with an IPv6-only host including in DCCP.
> b) The same would apply to UDP lite if MAP-T would also require UDP-lite
> translation.
> c) If a MAP-T CE communicates via a NAT64 (which is based on RFC6145, i.e.
> with DCCP optional), DCCP is broken if the NAT64 doesn't translate DCCP (as
> permitted by RFC6145).
> d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose DCCP
> translation, nodes complying with modified versions and those complying
> with previous versions wouldn't be guaranteed to interwork for DCCP.
>
> If we don't agree on this, there is still something to be clarified
> between us.
>

surely do not. RFC6146 clearly states:

   The current specification only defines how stateful NAT64 translates
   unicast packets carrying TCP, UDP, and ICMP traffic. Multicast
   packets and other protocols, including the Stream Control
   Transmission Protocol (SCTP), the Datagram Congestion Control
   Protocol (DCCP), and IPsec, are out of the scope of this
   specification.

- maoke


> If we agree, I have nothing else on this point.
>
> Regards,
> RD
>
>
>
> If, as you suggest,
> 2012-03-15 02:04, Maoke:
>
> 2012/3/14 Rémi Després <despres.remi@laposte.net>
>
>>
>> Le 2012-03-14 à 10:46, Maoke a écrit :
>>
>>
>> 2012/3/14 Rémi Després <despres.remi@laposte.net>
>>
>> ...
>
>
>>> Changing DCCP support from optional to mandatory in RFC6145 isn't
>>> backward compatible (an upgraded node isn't guaranteed to interwork with a
>>> non upgraded node).
>>>
>>
>> the CE/BR specified RFC6145-compliant might be a problem but MAP-T is
>> still in development. if we state to enforce DCCP mandatorily rather than
>> optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward
>> compatible problem. to this extend, MAP-T is at the same kick-off line of
>> the 4rd-U.
>>
>>
>> 1. I agree that, between CEs and BRs, there can be no problem for DCCP
>> (provided the draft is completed to this effect). The comparison table was
>> explicitly made with existing drafts, and intended to be updatable.
>>
>> 2. The MAP-T draft is also claimed to allow "communication between
>> IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only
>> servers in the domain that are using IPv4-mapped IPv6 address". In this
>> case, AFAIK, the backward compatibility problem exists
>> Thought?
>>
>
> surely it does not exist. that statement applies to the MAP-T-compliant
> equipments, when it is used as a IPv4-to-IPv6 single translator or as an
> native IPv6 router. same deployment of equipments should support
> double-translation, single-translation, and native IPv6 accesses
> simultanenously. that's one of the points of the MAP-T.
>
> - maoke
>
>
>>
>>
>>  To be even more precise, H6 of the comparison table can be:
>>> "For ISPs that don't provide all CE nodes, and for shared IPv4
>>> addresses, DCCP and UDP-Lite are supported, as well as future protocols
>>> using the TCP checksum algorithm and ports at the same place"
>>>
>>
>> i actually think the original text is fine. "For .... shared IPv4
>> addresses" is not needed for 4rd-U, to my understanding, nor needed to
>> MAP-T.
>>
>>
>> Will see what to do, then, when changes to the MAP-T draft concerning
>> DCCP are known.
>>
>
>> RD
>>
>>
>>
>>
>> maoke
>>
>>
>>>
>>> Does this cover the point?
>>>
>>> RD
>>>
>>>
>>>
>>>
>>>
>>> ;-)
>>> maoke
>>>
>>>
>>>>
>>>>  but this is not my point. my point is: there must be something we
>>>> don't know ("non omnia possumus omnes"). even we have gone through the
>>>> RFCs, there might be some other proprietary L4 protocols, or experimental
>>>> protocols. even they are minority, i don't think ignoring their existance
>>>> in our solution fits the spirit of the Internet. it might be argued that
>>>> NAT44 doesn't support such L4 protocols now, but an L4 protocol owner may
>>>> makes his own NAT44, either attached to the CE or separated. if 4rd-U
>>>> respects such an effort, it should state "currently blahblabla L4 protocols
>>>> are supported". the similar statement applies to the RFC6145 or MAP as well.
>>>>
>>>>
>>>> i somehow am hard to accept words like "far fetched theoretical
>>>> problem".
>>>>
>>>>
>>>> If I had thought it might be so, I would have avoided the word.
>>>>
>>>>
>>>> the L4-recalculate is a generic, architectural solution, surely needing
>>>> codes for every L4 protocol. but this generality in architecture makes
>>>> RFC6145 or MAP-T equipment be easily enhanced to support anything new with
>>>> the same logic. but for the 4rd-U BR, it looks to me we cannot have the
>>>> unified logic for all (even limited to existing and well-known) L4
>>>> protocols.
>>>>
>>>> only my 2 cents.
>>>>
>>>>
>>>> With amendments above, the point is AFAIK completely covered:
>>>> everything is rigorously true, and worth noting.
>>>> Thanks for the useful reference to the RDP of RFC1151.
>>>>
>>>> RD
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>
>
>