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 17:43 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 3015921F88BF for <softwires@ietfa.amsl.com>; Tue, 7 Feb 2012 09:43:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.438
X-Spam-Level:
X-Spam-Status: No, score=-6.438 tagged_above=-999 required=5 tests=[AWL=-0.739, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 IwQ5tpsHl+qx for <softwires@ietfa.amsl.com>; Tue, 7 Feb 2012 09:43:08 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 18DAC21F888A for <softwires@ietf.org>; Tue, 7 Feb 2012 09:43:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4772; q=dns/txt; s=iport; t=1328636586; x=1329846186; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=oKRkup7p2jKMSddSO+iLGzpMnHyOxYpyMyLFccr3mVA=; b=WkxPvbOJ7lWfY74ncb3RBmnHYkbkG7vVel3RyjchyAeiUFIjC4pZR53W JhsGwnW9hPe0TWx4Kl6qqWuAlCUQ/eEbhWcnpKxN/wtgDcYXUuhdf2QRL as/q3gUzoY40GbvG7f1dMgGjz4GR/ifFRV3W1foYxyTmsRawprdNlPRke s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAF5hMU+tJXG8/2dsb2JhbABDr1eBBYFyAQEBBAEBAQ8BHT4LDAQCAQgRBAEBAQoGFwEGASYfCQgBAQQTCBMHh2ObHwGefgSLNSs1DAKEMoJ2YwSIEzOfYg
X-IronPort-AV: E=Sophos;i="4.73,377,1325462400"; d="scan'208";a="54418438"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 07 Feb 2012 17:43:05 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q17Hh5gT010399; Tue, 7 Feb 2012 17:43:05 GMT
Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Feb 2012 11:43:05 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 7 Feb 2012 11:43:04 -0600
Message-ID: <067E6CE33034954AAC05C9EC85E2577C07508C68@XMB-RCD-111.cisco.com>
In-Reply-To: <C2F44548-5DB7-4C95-80C1-7AE6F07AD12D@laposte.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routingin hub&spoke topology
Thread-Index: AczlnFgFM5LbhtK2R0emdsFQuh5JVwAI4DOA
References: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net> <80C2DFB3-0E21-44F2-9FCA-F0B4CF88DA22@gmail.com> <2698466B-C775-4534-B60C-F4C0C2576B4A@laposte.net> <8EDD7EC1-55FC-4474-8688-7F473DEDE36E@cisco.com> <C2F44548-5DB7-4C95-80C1-7AE6F07AD12D@laposte.net>
From: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <despres.remi@laposte.net>
X-OriginalArrivalTime: 07 Feb 2012 17:43:05.0394 (UTC) FILETIME=[F252F920:01CCE5BF]
Cc: Softwires WG <softwires@ietf.org>, "Wojciech Dec \(wdec\)" <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 17:43:09 -0000

I would shy away from drawing that conclusion, given the implementation specifics.

Cheers,
Rajiv

> -----Original Message-----
> From: Rémi Després [mailto:despres.remi@laposte.net]
> Sent: Tuesday, February 07, 2012 8:28 AM
> To: Rajiv Asati (rajiva)
> Cc: Satoru Matsushima; Softwires WG; Wojciech Dec (wdec)
> Subject: Re: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routingin
> hub&spoke topology
> 
> 
> Le 2012-02-07 à 14:18, Rajiv Asati (rajiva) a écrit :
> 
> 
> 		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?
> 
> 
> 
> Yes indeed..
> Consistency check between source IPv4 address and source IPv6 address is
> always part of encapsulation solutions (translation or header-mapping solutions
> are not concerned).
> They are needed to avoid introducing vulnerability to spoofing attacks.
> 
> Cheers,
> RD
> 
> 
> 
> 
> 
> 
> 	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
> 
>