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 13:40 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 E5B4521F8762 for <softwires@ietfa.amsl.com>; Tue, 7 Feb 2012 05:40:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.019
X-Spam-Level:
X-Spam-Status: No, score=-3.019 tagged_above=-999 required=5 tests=[AWL=-0.320, 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 D0KJSR3LybfB for <softwires@ietfa.amsl.com>; Tue, 7 Feb 2012 05:40:09 -0800 (PST)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6400E21F8751 for <softwires@ietf.org>; Tue, 7 Feb 2012 05:40:09 -0800 (PST)
Received: by werm10 with SMTP id m10so6208304wer.31 for <softwires@ietf.org>; Tue, 07 Feb 2012 05:40:08 -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=x6lj5SHcIIhN0g43nA7zurp6Yr3k3CtdX4vi8H4OQ04=; b=BbTq1UWqUZfG81Lc7p4AW6z+6JWgmrzmY1EByzBFkViLoeHI107E6CiSRuwdLh1eXv 9V73/ceE5DtNsOye4ZGhJ/GnucIUvVBYoJpnQO1fVu9sEgBnTZ0IYK5Hwpp6oaD7389r P08WCosCdTvby+SHelQvIJK4+VubSty/DqiT4=
Received: by 10.216.133.18 with SMTP id p18mr5057465wei.1.1328622008008; Tue, 07 Feb 2012 05:40:08 -0800 (PST)
Received: from ams3-vpn-dhcp4282.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id eq5sm56784529wib.2.2012.02.07.05.40.05 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Feb 2012 05:40:07 -0800 (PST)
Sender: Ole Troan <ichiroumakino@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset="iso-8859-1"
From: Ole Trøan <otroan@employees.org>
In-Reply-To: <179E0E92-1E0F-414C-87CD-D782B9AF4577@laposte.net>
Date: Tue, 07 Feb 2012 14:40:04 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <38DA8E40-3A43-42DD-B08B-771EFF483DD6@employees.org>
References: <554901A7-F23C-4197-8783-85D51B502EA3@laposte.net> <48E1E89C-0CB2-4FE8-B3CB-13D556F46AE1@employees.org> <179E0E92-1E0F-414C-87CD-D782B9AF4577@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 13:40:11 -0000

Remi,

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

good question. anyone aware of an IETF document, giving a detailed description of why we deprecated automatic tunnels?
the best I can come up with, regarding IPv4 routes in IPv6 is:
http://www.windows-ipv6.org/index.php?page=implementation&selectlanguage=eng

> - Should we take it, then, that you reject moving from DS routing to IPV6-only routing without address/prefix changes as a use case you are interested in?

*talking about the general case here*
IPv4 addresses are used to number the outside of a CPE NAT, and can have relatively short address leases today. the resulting renumbering event only affects ongoing TCP sessions.

given that, it doesn't sound like the main use case for MAP.
it can be implemented in MAP, with a single rule as well; e.g. by assigning a separate IPv6 prefix /128 prefix to each CE.

what are we arguing over? if 4rd-U is better than MAP? in the MAP effort we chose to drop quite a number of suggested features, because we didn't think the added complexity/confusion was worth it. the working group are free to add any feature from the feature buffet.

cheers,
Ole