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

Maoke <fibrib@gmail.com> Thu, 06 October 2011 02:05 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 1A6991F0C67 for <softwires@ietfa.amsl.com>; Wed, 5 Oct 2011 19:05:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 c32-clqE8uf8 for <softwires@ietfa.amsl.com>; Wed, 5 Oct 2011 19:05:13 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1ED1F0C55 for <softwires@ietf.org>; Wed, 5 Oct 2011 19:05:13 -0700 (PDT)
Received: by qyk32 with SMTP id 32so4391630qyk.10 for <softwires@ietf.org>; Wed, 05 Oct 2011 19:08:22 -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=IjcczLCpIzvBA3bgyTM5uuaEHOOVmaZqaHNnSa8Gn3s=; b=R84jMnTuttQ5+N0WFvl6n7IeDokvPo0HKGz5GKbPCCJQ/238wWL347ZXAwMtTzeChr VgyaDOjaEQNAe6KqRyNHn0NgRy/VMRWNh2VNX0z64MkKqYKO+THi7QqZbtwm2XmTyuMM OgdPg4pemxyPHOZ5MaTM7Fgf9358I7QsG5DUY=
MIME-Version: 1.0
Received: by 10.229.199.105 with SMTP id er41mr119735qcb.69.1317866902355; Wed, 05 Oct 2011 19:08:22 -0700 (PDT)
Received: by 10.229.40.197 with HTTP; Wed, 5 Oct 2011 19:08:22 -0700 (PDT)
In-Reply-To: <CAM+vMERXwqJWobpUsk=Pq6OkubBSCc8QFdNsRgMSyzf+1e8SgQ@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>
Date: Thu, 06 Oct 2011 11:08:22 +0900
Message-ID: <CAFUBMqVkMQ89tffeGcBT5mJpz56mrvabe0pjdiJ-ia7XfoVhYw@mail.gmail.com>
From: Maoke <fibrib@gmail.com>
To: GangChen <phdgang@gmail.com>
Content-Type: multipart/alternative; boundary="0016e6d2792593802704ae97cc0d"
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 02:05:14 -0000

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?


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

 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?


>
>  Many thanks


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