Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01

Qiong <bingxuere@gmail.com> Thu, 07 June 2012 08:18 UTC

Return-Path: <bingxuere@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 D597C21F85AA for <softwires@ietfa.amsl.com>; Thu, 7 Jun 2012 01:18:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.448
X-Spam-Level:
X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 X3QEBOK0HVTw for <softwires@ietfa.amsl.com>; Thu, 7 Jun 2012 01:18:38 -0700 (PDT)
Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 59AE921F855B for <softwires@ietf.org>; Thu, 7 Jun 2012 01:18:38 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so227542ghb.31 for <softwires@ietf.org>; Thu, 07 Jun 2012 01:18:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PbbqR0B63iAh9J+2acnulhLTDjA9+cqtJjgya3W4kZc=; b=jK0EW3BGlImSR2q5UOYQh6DxvkssDOxkKjRNsNk5QbEufqUcAHAPk3hpal2C6aeUH0 /Q5fdThfhzfx/J2gQPWIxBK3GbEt+sXAKbeg9namA4T901tqIpA9l8WfKqW+kYGZG2a2 DJ+ESAa90AdmJiRpCSSgZXgREfytByxWL1SVkt/YGhy/R/oI2O9SJfz93sAU5Taj1g8X 1gwxenW+HT4wjHCq/PHIce6QzKIbGrFNH6nRlqUMBW9C7mCT7zEUHruMNk9e4SvSUV7F 3Q2zSC22Ranp+cruMOG5a12hgBTZh8Y7kk+iSW+080MeOs2S1jMbDTLmKQV1EooC2mxx LQ+g==
Received: by 10.60.171.135 with SMTP id au7mr1092626oec.62.1339057117818; Thu, 07 Jun 2012 01:18:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.76.12.35 with HTTP; Thu, 7 Jun 2012 01:17:57 -0700 (PDT)
In-Reply-To: <39098095-7D8B-44AA-9492-213283E89A4B@employees.org>
References: <CBF23F0B.21901%yiu_lee@cable.comcast.com> <39098095-7D8B-44AA-9492-213283E89A4B@employees.org>
From: Qiong <bingxuere@gmail.com>
Date: Thu, 07 Jun 2012 16:17:57 +0800
Message-ID: <CAH3bfAD1RoE7pqAj-9wLv2L6JJcgWtSH76d3S8vQOB=7HYzJBA@mail.gmail.com>
To: Ole Trøan <otroan@employees.org>
Content-Type: multipart/alternative; boundary="bcaec55405a6d76e4504c1dd87a3"
Cc: "softwires@ietf.org" <softwires@ietf.org>, Yong Cui <cuiyong@tsinghua.edu.cn>
Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01
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, 07 Jun 2012 08:18:40 -0000

Hi Ole,

>From the draft-ietf-softwire-stateless-4v6-motivation, the definition of
"Stateless 4/6 solution" is as follows:

Stateless 4/6 solution denotes a solution which does not require any
per-user state (see Section 2.3 of [RFC1958]) to be maintained by any IP
address sharing function in the Service Provider's network. This category
of solutions assumes a dependency between an IPv6 prefix and IPv4 address.

I think it clearly explained the motivation of MAP and 4rd, and this is
what we are seeking for in the design of any stateless solution.

If public 4over6 is one extreme case of MAP, in which one subscriber
represents one MAP domain, then should we also say that DS-Lite is another
extreme case of MAP, where one application (session) represents one MAP
domain ?

I think we should still keep the initial feature of these solutions.

Best wishes
Qiong

On Tue, Jun 5, 2012 at 2:06 AM, Ole Trøan <otroan@employees.org> wrote:

> Yiu,
>
> > AFAIK, this will couple the IPv4 address and IPv6 prefix. This isn't the
> > requirement for Public 4over6.
>
> with MAP you may embed parts of the IPv4 address into the IPv6 prefix and
> optionally a PSID.
> the remaining bits are provisioned with DHCP (or something else). how many
> bits you embed and how many bits you provision are an operational choice.
>
> if you move those levers to the end, with no embedded bits, with all bits
> provisioned, then you effectively have Public 4over6. no dependency between
> IPv4 and IPv6, as the IPV4 address is provisioned in the MAP DHCP option,
> independent of the IPv6 end user prefix. this implies one mapping rule or
> domain per tunnel (same amount of state as public 4over6 of course).
>
> is that still MAP, given that you don't have address mapping anymore?
> well, who knows, but my point was that you can achieve Public 4over6 with
> MAP.
>
> I didn't intend to put a spanner in the works of Public 4over6. it just
> occurred to me as I was looking at Public and Lightweight 4over6, as
> extensions to DS-lite. that we're basically talking about the exact same
> thing. the differences between the solutions, when we're talking about the
> hub and spoke 1:1 case (independence between IPv4 and IPv6 addresses), is
> how they are provisioned. MAP, DS-lite, Lightweight 4over6 and Public
> 4over6 are all equal when it comes to the amount of state on both sides as
> well as the bits on the wire.
>
> do we want 3-4 'point' mechanisms specified separately or do we want one
> mechanisms with multiple 'modes'?
>
> cheers,
> Ole
>
> >>>> public 4over6 is exactly the same as MAP in hub and spoke mode with
> >>>> one mapping rule per subscriber.
> >>>
> >>> Could you clarify how this relates to the MAP-rule definition saying
> >>> "Each MAP node in the domain has the same set of rules".
> >>> (draft-mdt-softwire-mapping-address-and-port-03)
> >>
> >> you can look at it as if each subscriber has his own MAP domain.
> >>
> >> cheers,
> >> Ole
> >>
> >> _______________________________________________
> >> Softwires mailing list
> >> Softwires@ietf.org
> >> https://www.ietf.org/mailman/listinfo/softwires
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>