Re: [v6ops] discussion of transition technologies

Mikael Abrahamsson <swmike@swm.pp.se> Tue, 23 January 2018 09:23 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAE4120725 for <v6ops@ietfa.amsl.com>; Tue, 23 Jan 2018 01:23:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbuy_9RPyTRq for <v6ops@ietfa.amsl.com>; Tue, 23 Jan 2018 01:23:15 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FE8C12DA17 for <v6ops@ietf.org>; Tue, 23 Jan 2018 01:23:14 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id B3625AF; Tue, 23 Jan 2018 10:23:12 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1516699392; bh=PKsO8tRedxvGwrY/BVLTPGX599vRrBnfP2olDMCdnU0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=idhvd7oedDRKo1wnP3MQRcbaFyn4vV01D44GJvtMkKQzV35L3pac3IxRIITAnE2nO CZMI3LF4Ovz4xMtN+kRrPDPlqVaXAYuc0Oc3G6N6XsIcXpfo/0TNYXDVbNuusVoP3Y iHpgb4f3WpZGl5jPncCDDw67sxxAYyVvG6y4iRNA=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9C0A29F; Tue, 23 Jan 2018 10:23:12 +0100 (CET)
Date: Tue, 23 Jan 2018 10:23:12 +0100 (CET)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Lee Howard <lee@asgard.org>
cc: Fred Baker <fredbaker.ietf@gmail.com>, "v6ops@ietf.org WG" <v6ops@ietf.org>
In-Reply-To: <D68BB100.9645A%lee@asgard.org>
Message-ID: <alpine.DEB.2.20.1801231020420.8884@uplift.swm.pp.se>
References: <D687BC24.92CC1%lee@asgard.org> <A6995969-0C03-4261-92F4-331206825130@gmail.com> <D29099E6-510D-41DA-B998-6BF15E9FDE7F@gmail.com> <D68B9BCE.96312%lee@asgard.org> <A5D8E026-ADB1-487C-AC20-30CA478A7B89@employees.org> <D68BA9E1.96407%lee@asgard.org> <70EABBF2-8572-4D6B-8C92-E1F3E247D527@gmail.com> <D68BB100.9645A%lee@asgard.org>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="-137064504-1767252296-1516699392=:8884"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/tbiY2Bbh1wvkkvL1OiHBUWmqgRg>
Subject: Re: [v6ops] discussion of transition technologies
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jan 2018 09:23:16 -0000

On Mon, 22 Jan 2018, Lee Howard wrote:

> Yes, I’m familiar with those use cases. They had edge networks that 
> couldn’t do IPv6. I haven’t seen provider edge equipment shipped in the 
> last ten years that is IPv6-incapable. I don’t think whether they had 
> business reasons for wanting IPv6.

I know edge platforms that work like this:

1. "Shared VLAN between customers, SAVI security for IPv4, drop all 
ethertypes that are not ARP or IPv4".

2. "No SAVI."

So if you chose option 1, to use this platform you have to move to a "one 
vlan per customer" type of deployment, for both IPv4 and IPv6, and use the 
upstream router to handle security. So this means changing the entire 
setup configuration, provisioning, fault finding tools etc.

Good luck finding business reasons to do that.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se