Re: [Softwires] MAP compatibility with DS-Lite

Xing Li <xing@cernet.edu.cn> Fri, 22 November 2013 13:46 UTC

Return-Path: <xing@cernet.edu.cn>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4DD1AE0B7 for <softwires@ietfa.amsl.com>; Fri, 22 Nov 2013 05:46:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJhDlI8zxnKv for <softwires@ietfa.amsl.com>; Fri, 22 Nov 2013 05:46:42 -0800 (PST)
Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 508CE1AE07C for <softwires@ietf.org>; Fri, 22 Nov 2013 05:46:41 -0800 (PST)
Received: from [127.0.0.1] (unknown [125.34.52.106]) by centos (Coremail) with SMTP id AQAAf3C7ZgWfX49STwYwAA--.7436S5; Fri, 22 Nov 2013 21:44:02 +0800 (CST)
Message-ID: <528F602F.1000009@cernet.edu.cn>
Date: Fri, 22 Nov 2013 21:46:23 +0800
From: Xing Li <xing@cernet.edu.cn>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Wojciech Dec <wdec.ietf@gmail.com>
References: <528D136C.60803@viagenie.ca> <CAFFjW4i7u0UQ7=oSJovwFBZeNr_VdJtTzOnTwZtuKz=f0VnDGQ@mail.gmail.com>
In-Reply-To: <CAFFjW4i7u0UQ7=oSJovwFBZeNr_VdJtTzOnTwZtuKz=f0VnDGQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-CM-TRANSID: AQAAf3C7ZgWfX49STwYwAA--.7436S5
X-Coremail-Antispam: 1UD129KBjvJXoW7Kr45CFW8KF1DurW5GFWfKrg_yoW8KF1UpF 4ftF13Kr4UJF1xJ34kXr109r1jvrWDt34xJ345tw10yFW5AF4vqF1kt3WrJrW8JryrGF1U JF4j9r1UWanxZrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUqGb7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_JFI_Gr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr0_ Cr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I8E87Iv6xkF7I0E14v26F4UJV W0owAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUXVWUAwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcVAKI48JMxkIecxEwVAFwVW5GwCF04k20xvY0x0EwIxGrwC20s026c02F40E 14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIx kGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAF wI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r 4j6F4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x07jr wIDUUUUU=
X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/
Cc: "softwires@ietf.org" <softwires@ietf.org>
Subject: Re: [Softwires] MAP compatibility with DS-Lite
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 22 Nov 2013 13:46:45 -0000

Wojciech Dec 写道:
>
>
>
> On 20 November 2013 20:54, Simon Perreault 
> <simon.perreault@viagenie.ca <mailto:simon.perreault@viagenie.ca>> wrote:
>
>     WG,
>
>     draft-ietf-softwire-map-08 contains this:
>
>     7.3. Backwards compatibility
>
>     A MAP-E CE provisioned with only the IPv6 address of the BR, and with
>     no IPv4 address and port range configured by other means, MUST
>     disable its NAT44 functionality. This characteristic makes a MAP CE
>     compatible with DS-Lite [RFC6333] AFTRs, whose addresses are
>     configured as the MAP BR.
>
>     In view of the recent discussions on provisioning, this
>     functionality strikes me as useless. There would be no reason for
>     an ISP to use such provisioning. A unified CPE would just do
>     DS-Lite if that's what's available.
>
>     I suggest to remove that section.
>
>
> You seem to equate ds-lite to being only there if it uses ds-lite 
> dhcpv6 extensions, which is not correct.
> Consider the case where a MAP deployment has a need (for whatever 
> reason) to direct some CPEs to an AFTR (stateful NAT). Instead of 
> rolling out Ds-lite DHCP extensions all over, it is trivially simple 
> to achieve the desired effect with the above MAP CE behaviour in place.
> This does not mean that those who want to use DS-lite dhcp extensions 
> cannot do so, if available. But it does mean that those who deploy 
> MAP, don't have to take care of mandating ds-lite dhcp extensions 
> "just in case" all over the shop.
> As such, the functionality is IMO useful, and almost trivial to 
> achieve in an implementation.

Agree with Woj and an exmaple is demostrated in Section 4.1 of 
http://www.ietf.org/id/draft-xli-softwire-map-testing-02.txt

Regards,

xing

>
> -Wojciech.
>
>
>     Simon
>     -- 
>     DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>     NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
>     STUN/TURN server --> http://numb.viagenie.ca
>     _______________________________________________
>     Softwires mailing list
>     Softwires@ietf.org <mailto:Softwires@ietf.org>
>     https://www.ietf.org/mailman/listinfo/softwires
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>