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

Satoru Matsushima <> Wed, 08 February 2012 12:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C1B8021F8606 for <>; Wed, 8 Feb 2012 04:43:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 79ECaVHtIqHw for <>; Wed, 8 Feb 2012 04:43:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E1B7121F84BF for <>; Wed, 8 Feb 2012 04:43:34 -0800 (PST)
Received: by werm10 with SMTP id m10so438458wer.31 for <>; Wed, 08 Feb 2012 04:43:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id eb6mr40955575wib.5.1328705014075; Wed, 08 Feb 2012 04:43:34 -0800 (PST)
Received: from [] ([]) by with ESMTPS id s8sm30728938wiz.8.2012. (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 <>
In-Reply-To: <>
Date: Wed, 08 Feb 2012 13:43:32 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: Rémi Després <>
X-Mailer: Apple Mail (2.1257)
Cc: Softwires WG <>, Wojciech Dec <>
Subject: Re: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routing in hub&spoke topology
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.