IETF Logo Mail Archive

Re: [v6ops] Bar BoF on a 6to4 replacement?

Iljitsch van Beijnum <iljitsch@muada.com> Thu, 13 November 2014 22:32 UTC

Return-Path: <iljitsch@muada.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F941AE04B for <v6ops@ietfa.amsl.com>; Thu, 13 Nov 2014 14:32:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.494
X-Spam-Level:
X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham
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 FoGaEGx-i-Jr for <v6ops@ietfa.amsl.com>; Thu, 13 Nov 2014 14:32:10 -0800 (PST)
Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E1161AE046 for <v6ops@ietf.org>; Thu, 13 Nov 2014 14:32:08 -0800 (PST)
Received: from dhcp-b324.meeting.ietf.org (dhcp-b324.meeting.ietf.org [31.133.179.36]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sADMVrpK002479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2014 23:31:55 +0100 (CET) (envelope-from iljitsch@muada.com)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <54652F3F.2090006@gmail.com>
Date: Thu, 13 Nov 2014 12:31:54 -1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <D312777F-C8F2-4ECC-9B14-2940A4A015CD@muada.com>
References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <AD4F3B9C-18D2-4B6F-867C-423368D6F489@muada.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <EB80E1B1-335F-45CA-BAFA-C2DB1BA58F1A@muada.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <alpine.DEB.2.02.1411132029560.25356@uplift.swm.pp.se> <D202E444-D659-447E-919A-10C6DB48A0BE@muada.com> <20141113195636.GY31092@Space.Net> <54652728.9040901@massar.ch> <54652F3F.2090006@gmail.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qcQREeOvbneTM5G_hdUAe80eyV0
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>
Subject: Re: [v6ops] Bar BoF on a 6to4 replacement?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 13 Nov 2014 22:32:11 -0000

On 13 Nov 2014, at 12:22, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:

> Goal - any new replacement of 6to4 must be future proof: avoid renumbering when 6to4-replacement dies out.  (this is what current tunnel brokers dont offer, they force one into a lockin going away from tunnel broker to native IPv6 one has renumber).

Are you saying that you want to be able to move from a tunnel to native without renumbering?

I don't think that's even a minor goal; renumbering is not a big deal in a home environment.

v2.46.0 | Report a Bug | By Email | System Status