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

Rémi Després <despres.remi@laposte.net> Tue, 07 February 2012 15:46 UTC

Return-Path: <despres.remi@laposte.net>
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 1D58321F8807 for <softwires@ietfa.amsl.com>; Tue, 7 Feb 2012 07:46:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.557
X-Spam-Level:
X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3]
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 642hrERgWTxw for <softwires@ietfa.amsl.com>; Tue, 7 Feb 2012 07:46:53 -0800 (PST)
Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by ietfa.amsl.com (Postfix) with ESMTP id EB93621F87FC for <softwires@ietf.org>; Tue, 7 Feb 2012 07:46:39 -0800 (PST)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id 1854170000E7; Tue, 7 Feb 2012 16:46:39 +0100 (CET)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id 946087000088; Tue, 7 Feb 2012 16:46:38 +0100 (CET)
X-SFR-UUID: 20120207154638607.946087000088@msfrf2216.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <despres.remi@laposte.net>
In-Reply-To: <656A0695-607C-4006-AC21-43E3FED31159@gmail.com>
Date: Tue, 7 Feb 2012 16:46:38 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <C8F656FD-67E6-4138-8DC5-2D1931D8A177@laposte.net>
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>
To: Satoru Matsushima <satoru.matsushima@gmail.com>
X-Mailer: Apple Mail (2.1084)
X-sfr-mailing: LEGIT
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 15:46:54 -0000

Le 2012-02-07 à 16:24, Satoru Matsushima a écrit :

> On 2012/02/07, at 16:10, Rémi Després wrote:
> 
>> 
>> Le 2012-02-07 à 15:26, Satoru Matsushima a écrit :
>> 
>>> On 2012/02/07, at 14:03, Rémi Després wrote:
>>> 
>>>> 
>>>> Le 2012-02-07 à 13:07, Satoru Matsushima a écrit :
>>>> 
>>>>> Hi Remi-san,
>>>>> 
>>>>> On 2012/02/07, at 11:13, Rémi Després wrote:
>>>>> 
>>>>>> Hello Ole, Tetsuya-san, Wojciech,
>>>>>> 
>>>>>> In a use case described in the 4rd-U draft (sec 5.3), an ISP replaces its dual-stack routing by IPv6-only routing.
>>>>>> For this, independently from the number of IPv4 prefixes it has to support, it uses only one mapping rule.
>>>>>> (By replacing each IPv4 route by an equivalent IPv6 route, it ensures that all customers keep their IPv4 addresses.)
>>>>>> 
>>>>> 
>>>>> I don't think that it could work as you explained in that section. For example, the BR would need to check a received packet from a CE whether it has correct source address in mapping rule or not. It means that the BR must know all address mappings for CE between IPv4 addresses and IPv6 prefixes. Is it correct understanding?
>>>> 
>>>> Ingress filtering of the domain has checked that the IPv6 source starts with the delegated IPv6 prefix, a /112 which includes the IPv4 address. In the 4rd-E case, the BR checks that the source address in the IPv4 header matches that of the IPv6 address. There is therefore no need for the BR to know all IPv4 prefixes. At its IPv4 interface, all received packets start with one of them. At its IPv6 interface, all packets it receives have an embedded address that starts with one of these prefixes. 
>>>> 
>>> 
>>> It looks like that you treat default mapping rule as a basic mapping rule to check source address consistency on the BR. It should work,
>> 
>> Yes, thanks.
>> 
>>> and the MAP too.
>> 
>> I don't see that.
>> The bit that, in 4rd-U hub&spoke, is changed for the CE-to-BR direction has been included precisely to support this case. 
>> Otherwise, packets sent by a CE to another CE would be routed directly to its destination, without a detour via a BR. 
>> 
> 
> I don't think so. I just mention BR behavior here.

Yes, but AFAIK the solution needs to involve CEs

> You mention CE behavior for whether the bit is set or not.

Yes, please see below.

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



> --satoru
> 
>