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

"Rajiv Asati (rajiva)" <rajiva@cisco.com> Tue, 07 February 2012 13:18 UTC

Return-Path: <rajiva@cisco.com>
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 96D6221F86D0 for <softwires@ietfa.amsl.com>; Tue, 7 Feb 2012 05:18:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.631
X-Spam-Level:
X-Spam-Status: No, score=-3.631 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067]
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 BuSYUbYSxVa0 for <softwires@ietfa.amsl.com>; Tue, 7 Feb 2012 05:18:10 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2C86621F86C9 for <softwires@ietf.org>; Tue, 7 Feb 2012 05:18:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=13260; q=dns/txt; s=iport; t=1328620690; x=1329830290; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=zUNj7PvxUe3I5DoyhRs9YzQ/6AfKkLhdOhj11UIUICI=; b=fNUA3yWYVM6L8JKBdCiJ2X9PnGwTGL78/+cst7NV0l43VrHph+QIKUkS 7x8s8z6qBdVg+SbzVRvfU9pGYg7v2jO9/Dlr4x1eRPVQidnVcHS8hBVUd nm0HnF8h+8KluU8Gf3sd+UkglDn+l+EvgJo0nF0cUqOYQyGmaRPS2Kes/ U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkYGALUjMU+rRDoG/2dsb2JhbABDhQupUm4CgQWBcgEBAQMBAQEBDwEQSwsFCwIBCBgCAiYCAgIlMAEBBBMih1oJm0kBjGWSIwSBL4oGASk3AQcHAoMEBRgCCwIFHAgLIyaCQzNjBIhGjGaOPIQ/
X-IronPort-AV: E=Sophos; i="4.73,377,1325462400"; d="scan'208,217"; a="29097737"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 07 Feb 2012 13:18:10 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q17DI9kN018043; Tue, 7 Feb 2012 13:18:09 GMT
Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Feb 2012 07:18:09 -0600
Received: from 144.254.231.93 ([144.254.231.93]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Tue, 7 Feb 2012 13:18:09 +0000
References: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net> <80C2DFB3-0E21-44F2-9FCA-F0B4CF88DA22@gmail.com> <2698466B-C775-4534-B60C-F4C0C2576B4A@laposte.net>
Content-Transfer-Encoding: 7bit
From: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
Thread-Topic: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routingin hub&spoke topology
Thread-Index: Aczlmu8+Qyjycgt8RdakpxbHm5D5zw==
Content-Type: multipart/alternative; boundary="Apple-Mail-201C0DEA-2789-4114-AE9D-15E2C13D541A"; charset="UTF-8"
In-Reply-To: <2698466B-C775-4534-B60C-F4C0C2576B4A@laposte.net>
Message-ID: <8EDD7EC1-55FC-4474-8688-7F473DEDE36E@cisco.com>
Date: Tue, 7 Feb 2012 08:18:06 -0500
To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= <despres.remi@laposte.net>
MIME-Version: 1.0 (1.0)
X-OriginalArrivalTime: 07 Feb 2012 13:18:09.0328 (UTC) FILETIME=[EF87CB00:01CCE59A]
Cc: Softwires WG <softwires@ietf.org>, Wojciech Dec <wdec@cisco.com>
Subject: Re: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routingin 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:18:16 -0000

> the 4rd-E case, the BR checks that the source address in the IPv4 header matches that of the IPv6 address. 

Could this check (and filtering) be done without incurring a performance penalty? 

Cheers,
Rajiv

Sent from my Phone

On Feb 7, 2012, at 8:03 AM, Rémi Després <despres.remi@laposte.net> wrote:

> 
> Le 2012-02-07 à 13:07, Satoru Matsushima a écrit :
> 
>> Hi Remi-san,
>> 
>> On 2012/02/07, at 11:13, Rémi Després wrote:
>> 
>>> Hello Ole, Tetsuya-san, Wojciech,
>>> 
>>> 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.)
>>> 
>> 
>> 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. 
> 
>> 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?
>> 
>> cheers,
>> --satoru
>> 
>>> 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.
>>> 
>>> 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?
>>> 
>>> Cheers,
>>> RD
>>> 
>>> _______________________________________________
>>> Softwires mailing list
>>> Softwires@ietf.org
>>> https://www.ietf.org/mailman/listinfo/softwires
>> 
> 
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires