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

Ole Trøan <otroan@employees.org> Tue, 07 February 2012 12:16 UTC

Return-Path: <ichiroumakino@gmail.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 7414621F86B3 for <softwires@ietfa.amsl.com>; Tue, 7 Feb 2012 04:16:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.042
X-Spam-Level:
X-Spam-Status: No, score=-3.042 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 dMGe2rIWj5Xt for <softwires@ietfa.amsl.com>; Tue, 7 Feb 2012 04:16:38 -0800 (PST)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id B63F121F86B2 for <softwires@ietf.org>; Tue, 7 Feb 2012 04:16:37 -0800 (PST)
Received: by wibhm9 with SMTP id hm9so6239704wib.31 for <softwires@ietf.org>; Tue, 07 Feb 2012 04:16:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=SJkWjQTHu1sU1/pSfxcWTQH4GZ/7qHJgf6jTKz0g/Go=; b=UGcomEISLv9YPc6/avuh5NKqlmtcLbOE++5sLKT/N/f/j7RcwGXT1y3fu71FISv/eU R3sfPLqR8oYQG8B9jOHfT/I97b8jes5IDSyU9QFf/g+rMMILbGj8xnnzo7DF4eb5sESe EPc10grxk/iAqsuwBA/7/XLgWtm3M6FnvJQi8=
Received: by 10.180.83.97 with SMTP id p1mr22832375wiy.19.1328616996924; Tue, 07 Feb 2012 04:16:36 -0800 (PST)
Received: from dhcp-10-61-103-54.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id n5sm56095943wiw.7.2012.02.07.04.16.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Feb 2012 04:16:36 -0800 (PST)
Sender: Ole Troan <ichiroumakino@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset="us-ascii"
From: Ole Trøan <otroan@employees.org>
In-Reply-To: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net>
Date: Tue, 07 Feb 2012 13:16:35 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <48E1E89C-0CB2-4FE8-B3CB-13D556F46AE1@employees.org>
References: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net>
To: Rémi Després <despres.remi@laposte.net>
X-Mailer: Apple Mail (2.1257)
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 12:16:38 -0000

Remi,

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

injecting IPv4 routing into the IPv6 routing table is considered a bad idea. that was what caused Automatic tunnelling and IPv4 compatible address in RFC1933 to be deprecated.

cheers,
Ole