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: <91E90DC9-99EC-44C2-89A9-7ED42E83701C@gmail.com>
Date: Tue, 7 Feb 2012 16:10:39 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <3168C356-BDB1-4067-B4FB-3DBC993FA997@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>
To: Satoru Matsushima <satoru.matsushima@gmail.com>
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
Precedence: list

Le 2012-02-07 =E0 15:26, Satoru Matsushima a =E9crit :

> On 2012/02/07, at 14:03, R=E9mi Despr=E9s wrote:
>=20
>>=20
>> Le 2012-02-07 =E0 13:07, Satoru Matsushima a =E9crit :
>>=20
>>> 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?
>>=20
>> 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
>>=20
>=20
> 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.=20
Otherwise, packets sent by a CE to another CE would be routed directly =
to its destination, without a detour via a BR.=20


>>> I think that operators who already deploy such dual-stack network is =
supposed that they have address mapping table,
>>=20
>> 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.
>=20
> 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.


Cheers,
RD



>=20
>=20
> cheers,
> --satoru
>=20
>>=20
>> Regards,
>> RD
>>=20
>>=20
>>=20
>>> 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
>>=20
>=20