Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation

Congxiao Bao <cx.cernet@gmail.com> Thu, 06 October 2011 06:14 UTC

Return-Path: <cx.cernet@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 A080A21F8C4F for <softwires@ietfa.amsl.com>; Wed, 5 Oct 2011 23:14:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.318
X-Spam-Level:
X-Spam-Status: No, score=-3.318 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 abtzk4Qc0rp6 for <softwires@ietfa.amsl.com>; Wed, 5 Oct 2011 23:14:51 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B98DC21F8C4E for <softwires@ietf.org>; Wed, 5 Oct 2011 23:14:51 -0700 (PDT)
Received: by ywm3 with SMTP id 3so2800206ywm.31 for <softwires@ietf.org>; Wed, 05 Oct 2011 23:18:01 -0700 (PDT)
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=jVEgbbeRpzy1IUO4O0/9WRJLxzX+wGbU9tYognzUbpc=; b=WoPQKAdSjgg4HyeBfLdjZzyPS8ptGdQPhqfDvDYXiwUIFyECRGMuFb22oFhMNdyY7Q xt0lKRiXx9WxspSv3gq67RfmETyODxI3QeSB7HWZMIAATzEmMtCdARgEgYkIRgpgAbjj xzrbbXkZEBUUKfJjxyX/8qIjL1+XYwYJPRIzk=
MIME-Version: 1.0
Received: by 10.68.15.194 with SMTP id z2mr3125215pbc.47.1317881879903; Wed, 05 Oct 2011 23:17:59 -0700 (PDT)
Received: by 10.142.162.1 with HTTP; Wed, 5 Oct 2011 23:17:59 -0700 (PDT)
In-Reply-To: <CAFUBMqVkMQ89tffeGcBT5mJpz56mrvabe0pjdiJ-ia7XfoVhYw@mail.gmail.com>
References: <F259BF79-B3C9-4434-AAC4-9F84B8D9A0FA@laposte.net> <CAM+vMER2CBTpYOhcu63th7AJejCJ4sv0_GqeiZmwHVHEEeW1WA@mail.gmail.com> <0C2B5428-98D4-4F67-B18D-9ACA946A68E7@laposte.net> <CABv173VeFd5DVLm5XvX5+PTgW2biQpUCnW=Z7EXHj7EDG-5LUg@mail.gmail.com> <CAM+vMERXwqJWobpUsk=Pq6OkubBSCc8QFdNsRgMSyzf+1e8SgQ@mail.gmail.com> <CAFUBMqVkMQ89tffeGcBT5mJpz56mrvabe0pjdiJ-ia7XfoVhYw@mail.gmail.com>
Date: Thu, 06 Oct 2011 14:17:59 +0800
Message-ID: <CABv173U4wOBYBjM+kaCfHM1ksNPSk1WW_JvMTf1Y1=b_-X=jrg@mail.gmail.com>
From: Congxiao Bao <cx.cernet@gmail.com>
To: Maoke <fibrib@gmail.com>
Content-Type: multipart/alternative; boundary="bcaec51f995f4ebe6b04ae9b497e"
Cc: Softwires-wg <softwires@ietf.org>
Subject: Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation
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, 06 Oct 2011 06:14:52 -0000

Hi, Gang, Maoke

2011/10/6 Maoke <fibrib@gmail.com>

> hi Gang,
>
> trying to understand your point, may i follow your message inline? sorry if
> my questions are trial/naive.
>
>  2011/10/6 GangChen <phdgang@gmail.com>
>
>> Hello Congxiao,
>>
>> Thanks for the discussion.
>> Please see my reply inline.
>>
>> 2011/10/5, Congxiao Bao <cx.cernet@gmail.com>:
>> >> > There are no necessary to put IPv4 and Port-set ID information in
>> last
>> >> > 64 bits.
>> >>
>> >> The CE Pv6 prefix included in the /64 Subnet prefix isn't self
>> delimited,
>> >> so that the length of the CE index can't be determined in this part of
>> the
>> >> address.
>> >> Having the length of the A or A+P prefix in the IID completes what is
>> >> needed to derive the CE port-set.
>> >
>> > Besides, if a medium or large size ISP can’t get short enough IPv6
>> prefix
>> > (ex. /24), the first 64 bits can not contain the whole IPv4 32 bits,
>> which
>> > cannot make the double translation successful.
>>
>> I guess that is depending on a specific algorithm. I don't see such
>> limitation in 4v6
>> translation(
>> http://tools.ietf.org/html/draft-murakami-softwire-4v6-translation-00)
>>
>>
> i couldn't understand why we "don't see such limitation in 4v6
> translation". 4via6 translate the private ipv4 address with 4rd mapping rule
> while the public ipv4 address with RFC6052 algorithm, right? can the both
> case work fine if an ISP can only get a fairly long IPv6 prefix, like /40 or
> even longer?
>

Yes, if ISP has /32 IPv6 address, then how to embed 32 bits IPv4 address and
PSID in the first 64 bits?

>
>
>>
>> > The ISP is not able to achieve per-host traffic control without a
>> standard
>> > defining last 64 bits. If the ISP does, why not use IPv4+psid in suffix
>> > naturally instead of other new bits definition?
>>
>> First off, I'm not sure per-host traffic control is a common case for
>> network operations
>>
>
> i think it is common for, maybe, not any network operators but at least
> some operators. especially for those running middle-to-small ISP services
> (like my company), the capability of per-host traffic control is definitely
> needed. a specific but not rare case is suppressing the pathologically
> greedy download/upload behavior of bot-net boxes.
>

Agree.

>
>  Secondly, it could be possible to use first 64 bits differentiating
>
>  hosts. Please see Max PSID usage in
>
> http://tools.ietf.org/html/draft-despres-softwire-4rd-addmapping-01#page-15
>>
>
> sorry but i may not yet understand the mapping algorithm. is the Rule IPv6
> prefix definitely short enough to take all Max CE in the first 64 bits?
> again, what if an ISP can only get a fairly long IPv6 prefix?
>
>
 For per-host traffic, the prefix length of ACL should be /128. In this
case, you have to specify the value of the suffix. So different ISPs in the
IPv6 data path can implement IPv6 ACL without additional knowledge.



Congxiao

>
>>  Many thanks
>
>
>> Gang
>>
>>  _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>>
>
>