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

Rémi Després <> Tue, 07 February 2012 16:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 267B021F883D for <>; Tue, 7 Feb 2012 08:53:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.542
X-Spam-Status: No, score=-1.542 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fwe1Nk6NVRJ2 for <>; Tue, 7 Feb 2012 08:53:34 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 41A3221F8832 for <>; Tue, 7 Feb 2012 08:53:33 -0800 (PST)
Received: from (localhost []) by (SMTP Server) with ESMTP id DA3A57000176; Tue, 7 Feb 2012 17:53:32 +0100 (CET)
Received: from [] ( []) by (SMTP Server) with ESMTP id 280A77000189; Tue, 7 Feb 2012 17:53:32 +0100 (CET)
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?= <>
In-Reply-To: <>
Date: Tue, 7 Feb 2012 17:53:31 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Satoru Matsushima <>
X-Mailer: Apple Mail (2.1084)
X-sfr-mailing: LEGIT
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: Tue, 07 Feb 2012 16:53:35 -0000

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.  

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


> cheers,
> --satoru