Re: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routing in hub&spoke topology

Satoru Matsushima <satoru.matsushima@gmail.com> Tue, 07 February 2012 16:35 UTC

Return-Path: <satoru.matsushima@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 4AC3121F885D for <softwires@ietfa.amsl.com>; Tue, 7 Feb 2012 08:35:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, 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 1cV8MoheDFNq for <softwires@ietfa.amsl.com>; Tue, 7 Feb 2012 08:35:29 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED6421F8848 for <softwires@ietf.org>; Tue, 7 Feb 2012 08:35:29 -0800 (PST)
Received: by wgbdt10 with SMTP id dt10so5463881wgb.13 for <softwires@ietf.org>; Tue, 07 Feb 2012 08:35:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=YPlGmf9f4gmKhpG6mXlm4MhHAz1iImznI4uKIOu/VfA=; b=WcqvGao6sfdqKYf5Z/sBIs3M/D0wD0MOrYqfP/b1RmNsPkmdOl95kHuKprC1qmdut1 /cZYVsUawK4OeJlvqTDfkULhJft3OPgE7g2kp2FEUdcn7jHtHLc9HZlsKAtNBLabYrxU FmiQO2QtvXa4/wfxS2DcQxksjZJQDSegB0Xbs=
Received: by 10.180.90.194 with SMTP id by2mr35376005wib.5.1328632528709; Tue, 07 Feb 2012 08:35:28 -0800 (PST)
Received: from [10.115.194.117] (62-50-193-163.client.stsn.net. [62.50.193.163]) by mx.google.com with ESMTPS id cb8sm33210789wib.0.2012.02.07.08.35.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Feb 2012 08:35:27 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Satoru Matsushima <satoru.matsushima@gmail.com>
In-Reply-To: <C8F656FD-67E6-4138-8DC5-2D1931D8A177@laposte.net>
Date: Tue, 7 Feb 2012 17:35:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <0D7DCA45-36EF-4D43-AD36-B7851D8CE73E@gmail.com>
References: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net> <80C2DFB3-0E21-44F2-9FCA-F0B4CF88DA22@gmail.com> <2698466B-C775-4534-B60C-F4C0C2576B4A@laposte.net> <91E90DC9-99EC-44C2-89A9-7ED42E83701C@gmail.com> <3168C356-BDB1-4067-B4FB-3DBC993FA997@laposte.net> <656A0695-607C-4006-AC21-43E3FED31159@gmail.com> <C8F656FD-67E6-4138-8DC5-2D1931D8A177@laposte.net>
To: =?utf-8?Q?R=C3=A9mi_Despr=C3=A9s?= <despres.remi@laposte.net>
X-Mailer: Apple Mail (2.1257)
Cc: Softwires WG <softwires@ietf.org>, Wojciech Dec <wdec@cisco.com>
Subject: Re: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routing in hub&spoke topology
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: Tue, 07 Feb 2012 16:35:30 -0000

On 2012/02/07, at 16:46, Rémi Després wrote:

--snip--

>>> 
>>>>>> I think that operators who already deploy such dual-stack network is supposed that they have address mapping table,
>>>>> 
>>>>> I would rather suppose that ISPs that have added IPv6-prefix delegation, say /56s, to an existing IPv4 network did it without mixing their IPv6 plan with their IPv4 prefixes.
>>>>> I am ready, however, to look seriously at individual cases where choices were different.
>>>> 
>>>> Basically provision MAP CE is based on its delegated IPv6 prefix in concept. It is opposed to your case but technically possible.
>>> 
>>> 
>>>> Now I concern that it requires much complicated CE implementation.
>>> 
>>> All what is required is that CEs set an address bit if hub&spoke topology is required.
>>> 
>> 
>> So how CE decide to set the bit, and when the CE figure it out?
> 
> The CE knows it must set this bit if, and only if, it received at initialization a Topology-variant parameter set to Hub&spoke (sec 4.1).
> In this case, the CE sets bit 79 to 1 in IPv6 destination addresses of all packets it sends.
> 
> BTW, this bit should better, for clarity, be given a name, e.g. bit B meaning To-BR bit (or whatever better idea one could propose). I plan to do it in the next version.
> 

So you mean that if the hub&spoke bit is set, a CE derives /112 IPv6 prefix as 4rd end point from IPv4 address which is already assigned. Otherwise, a CE derives its IPv4 address from delegated IPv6 prefix. right?

cheers,
--satoru