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 414B221F8747 for <softwires@ietfa.amsl.com>;
 Tue,  7 Feb 2012 05:03:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.300,
 BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
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 sKpn4UFBFsKh for
 <softwires@ietfa.amsl.com>; Tue,  7 Feb 2012 05:03:33 -0800 (PST)
Received: from smtp1-g21.free.fr (smtp1-g21.free.fr
 [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id
 64BDF21F8642 for <softwires@ietf.org>; Tue,  7 Feb 2012 05:03:31 -0800 (PST)
Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown
 [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix)
 with ESMTP id EBC7F9401A8; Tue,  7 Feb 2012 14:03:19 +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?= <despres.remi@laposte.net>
In-Reply-To: <80C2DFB3-0E21-44F2-9FCA-F0B4CF88DA22@gmail.com>
Date: Tue, 7 Feb 2012 14:03:18 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <2698466B-C775-4534-B60C-F4C0C2576B4A@laposte.net>
References: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net>
 <80C2DFB3-0E21-44F2-9FCA-F0B4CF88DA22@gmail.com>
To: Satoru Matsushima <satoru.matsushima@gmail.com>
X-Mailer: Apple Mail (2.1084)
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 13:03:34 -0000

Le 2012-02-07 =E0 13:07, Satoru Matsushima a =E9crit :

> Hi Remi-san,
>=20
> On 2012/02/07, at 11:13, R=E9mi Despr=E9s wrote:
>=20
>> Hello Ole, Tetsuya-san, Wojciech,
>>=20
>> 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.)
>>=20
>=20
> 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.=20

> 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.

Regards,
RD



> they can provision each CE individually, and also they are capable to =
distribute the default mapping rule since they should install it into =
the CEs. In that situation, what's the motivation of why the operator =
want to provision with only default mapping rule?
>=20
> cheers,
> --satoru
>=20
>> For this to work, the 4rd-U draft has a bit that, in the hub&spoke =
case, differs between CE-to-BR and BR-to-CE directions. Thus, packets =
sent to a CE take different routes depending on whether sent by a CE or =
a BR.
>>=20
>> I don't see how the equivalent could work with the MAP documents you =
edited.
>> Is it that such a use case is out of scope for MAP?
>> Or did I miss something?
>>=20
>> Cheers,
>> RD
>>=20
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>=20

