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

Satoru Matsushima <satoru.matsushima@gmail.com> Wed, 08 February 2012 12:43 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 C1B8021F8606 for <softwires@ietfa.amsl.com>; Wed, 8 Feb 2012 04:43:35 -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 79ECaVHtIqHw for <softwires@ietfa.amsl.com>; Wed, 8 Feb 2012 04:43:35 -0800 (PST)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E1B7121F84BF for <softwires@ietf.org>; Wed, 8 Feb 2012 04:43:34 -0800 (PST)
Received: by werm10 with SMTP id m10so438458wer.31 for <softwires@ietf.org>; Wed, 08 Feb 2012 04:43:34 -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=g7QlqZc0U6rC+6Hi2uhBf/fBhsgmAUvktyGW2ZLGfSY=; b=iwMaTrmMTsCnl1khyYaNLpNCft5vly5F20wVAYFh0iQsvtyz79VbrUwTO2sSwtfl+X X/97DIHsX/gAg5gMn05UCD77RnSuZuV20sbsofi8joyxqjt/kI5V6PXTeJpWfPYuJB8A 01DEkA7a03taS6tXxCwpjuLzyAmWBn/Kz7bg8=
Received: by 10.180.97.166 with SMTP id eb6mr40955575wib.5.1328705014075; Wed, 08 Feb 2012 04:43:34 -0800 (PST)
Received: from [10.115.196.129] ([46.245.241.99]) by mx.google.com with ESMTPS id s8sm30728938wiz.8.2012.02.08.04.43.33 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Feb 2012 04:43:33 -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: <CD7CC0F7-DE48-426F-B95F-8024BD09689D@laposte.net>
Date: Wed, 8 Feb 2012 13:43:32 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8032174F-2879-45D0-9E20-62899126EAC6@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> <0D7DCA45-36EF-4D43-AD36-B7851D8CE73E@gmail.com> <CD7CC0F7-DE48-426F-B95F-8024BD09689D@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: Wed, 08 Feb 2012 12:43:35 -0000

On 2012/02/07, at 17:53, Rémi Després wrote:

> 
> Le 2012-02-07 à 17:35, Satoru Matsushima a écrit :
> 
>> 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.
> 
> 
> If the CE is delegated a prefix shorter than /64, it isn't concerned with the To-BR bit.
> If it is delegated a /112, it finds its IPv4 address inom it. 
> It then must set the To-BR bit, in its outgoing IpV6 destinations, iff the Topology variant is Hub&spoke.  
> 

As you described in your draft, if a CE is delegated /112 IPv6 prefix, the CE automatically form itself for H&S mode and extract a non-sharing IPv4 address from the /112 prefix.

> 
>> Otherwise, a CE derives its IPv4 address from delegated IPv6 prefix. right?
> 
> The CE always derives its 4rd prefix from its delegated IPv6 prefix, based on the Mapping rule that has the longest match.
> 

So you mean that it is only specific case of which if the extracted IPv4 address is same with an address assigned to a dual-stack interface on the CE, the default route on the CE is forced to the BR, and keep that address on the dual-stack interface as NAPT source address. Is that what you request to 4rd-U CE implementation?

It also requires operator to manage specific /112 route for each CE that means IPv4 host routes are injected to the operator's IPv6 routing table that's what Ole already pointed out. I agree with Ole that I'm doubt it could be widely acceptable technique for operators.

cheers,
--satoru