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

Rémi Després <despres.remi@laposte.net> Wed, 08 February 2012 18:33 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 C1F4921F8592 for <softwires@ietfa.amsl.com>; Wed, 8 Feb 2012 10:33:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.559
X-Spam-Level:
X-Spam-Status: No, score=-1.559 tagged_above=-999 required=5 tests=[AWL=-0.210, 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 0aL9Zzh-wWg0 for <softwires@ietfa.amsl.com>; Wed, 8 Feb 2012 10:33:41 -0800 (PST)
Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id D57E821F855B for <softwires@ietf.org>; Wed, 8 Feb 2012 10:33:40 -0800 (PST)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2414.sfr.fr (SMTP Server) with ESMTP id 566AF7000435; Wed, 8 Feb 2012 19:33:39 +0100 (CET)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2414.sfr.fr (SMTP Server) with ESMTP id 629AB700042F; Wed, 8 Feb 2012 19:33:38 +0100 (CET)
X-SFR-UUID: 20120208183338405.629AB700042F@msfrf2414.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: <8032174F-2879-45D0-9E20-62899126EAC6@gmail.com>
Date: Wed, 8 Feb 2012 19:33:38 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <30435679-4CFA-4B9C-A68B-E55722987E6D@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> <C8F656FD-67E6-4138-8DC5-2D1931D8A177@laposte.net> <0D7DCA45-36EF-4D43-AD36-B7851D8CE73E@gmail.com> <CD7CC0F7-DE48-426F-B95F-8024BD09689D@laposte.net> <8032174F-2879-45D0-9E20-62899126EAC6@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: Wed, 08 Feb 2012 18:33:41 -0000

Le 2012-02-08 à 13:43, Satoru Matsushima a écrit :

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

Hub&spoke vs Mesh is independent from /112.
Otherwise, yes, a CE always derives its IPv4 address when it receives a /112 matching the default mapping rule.

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

Yes, by setting the ToBR bit.

> and keep that address on the dual-stack interface as NAPT source address. Is that what you request to 4rd-U CE implementation?

I think so.

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

Well, an ISP has assigned that has assigned fixed IPv4 addresses, and wants to keep them while moving to IPv6-only routing needs, one way or another, to reflect IPv4 routes in IPv6. 

> I agree with Ole that I'm doubt it could be widely acceptable technique for operators.

It is useful for ISPs that have this use case, even if there aren't many, and in any case creates no harm for others.
It is a way to encourage IPv6 routing for ISPs that don't want to maintain DS routing.

RD






> 
> cheers,
> --satoru
>