IETF Logo Mail Archive

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

Iljitsch van Beijnum <iljitsch@muada.com> Wed, 12 November 2014 21:06 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 BDB571AD04C for <v6ops@ietfa.amsl.com>; Wed, 12 Nov 2014 13:06:24 -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 IPrwHrALeBBN for <v6ops@ietfa.amsl.com>; Wed, 12 Nov 2014 13:06:21 -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 C790D1AD01C for <v6ops@ietf.org>; Wed, 12 Nov 2014 13:06:17 -0800 (PST)
Received: from t2001067c037001766d42b7fe0f548b94.wireless-a.v6.meeting.ietf.org (t2001067c037001766d42b7fe0f548b94.wireless-a.v6.meeting.ietf.org [IPv6:2001:67c:370:176:6d42:b7fe:f54:8b94] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sACL63nv093543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2014 22:06:06 +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: <5463C52C.8060908@massar.ch>
Date: Wed, 12 Nov 2014 11:06:05 -1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <AE0A44F7-59D9-472F-AC00-2F9026626BCC@muada.com>
References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <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> <5463C52C.8060908@massar.ch>
To: Jeroen Massar <jeroen@massar.ch>
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/B5RJh-JlhnkHbPiY_VN5cko6_KM
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: Wed, 12 Nov 2014 21:06:24 -0000

On 12 Nov 2014, at 10:38, Jeroen Massar <jeroen@massar.ch> wrote:

>> that works pretty reliably (unlike 6to4).

> "pretty reliably" or "reliable"

Nothing is perfect in this world, but the idea is that it should be so reliable that it can safely be turned on "set and forget" by default.

> As somebody who is terminating an extreme amount of tunnels to get those
> people who don't have native IPv6 some IPv6: can you provide more
> details please of what direction you are thinking of?

Sure.

> What does 6rd not resolve and what does this better?

6rd requires cooperation from your ISP. Now if your ISP offers 6rd, you should use it. But a third-party home gateway doesn't necessarily know how to configure itself to use 6rd for your ISP. If your ISP doesn't do 6rd but you have a SixXS account, you'll want to use that account and set up an AYIYA tunnel - but only if your home gateway supports AYIYA. But maybe you have a public IPv4 address so you could use a proto 41 tunnel.

Today, determining all of this, selecting the right tunnel and then configuring at least some parameters are done manually. Which is a non-starter for most users. The draft aims not so much to come up with a new tunneling mechanism but rather to allow devices to find and configure existing tunneling options.

However, I do think it will be necessary to define an additional tunneling option that's simple to implement that could be the "mandatory to implement" default one.

> And as below you are asking for HTTP things, what is it that TSP and TIC
> do not resolve or do 'incorrectly'?

The main issue is that you need to talk to someone who runs TSP or TIC. So this wouldn't address the case where an ISP runs 6rd. Or you have an account at a tunnel broker that doesn't use TSP or TIC (yes, I know, hard to imagine).

> Note that there is no magic "IPv6 Tunnel Broker Discovery".

So let's invent it!

>>  * Would using plain text similar to HTTP headers to
>>  pass parameters be better?

> Depends completely on what you are talking about. Examples would be useful.

Login: 02a9fb33ec0a@homegateways.org
Password: ALLYOURBASE64AREBELONGTOUS
Encap-Supported: proto41, rfc5969, net.sixxs.ayiya
Negotiation-Supported: DHCPv6-PD, DHCPv6-IA, rfc4862, net.sixxs.tic
Client-Address: 100.64.0.1
Client-Type: router

v2.23.0 | Report a Bug | By Email