Re: [v6ops] v6-only (with NAT64) as default network during a conference?

George Michaelson <ggm@algebras.org> Thu, 23 January 2014 01:48 UTC

Return-Path: <ggm@algebras.org>
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 197101A037C for <v6ops@ietfa.amsl.com>; Wed, 22 Jan 2014 17:48:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 EIMBmnbxoqY9 for <v6ops@ietfa.amsl.com>; Wed, 22 Jan 2014 17:48:36 -0800 (PST)
Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id 458751A03A7 for <v6ops@ietf.org>; Wed, 22 Jan 2014 17:48:36 -0800 (PST)
Received: by mail-pb0-f49.google.com with SMTP id up15so1176997pbc.36 for <v6ops@ietf.org>; Wed, 22 Jan 2014 17:48:35 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PWM4jVNAt5+JHMdxOsoN5lPkjI7KRCzTWdCcor3S2xg=; b=Abd4IFAsRipDd3vSjxGdMkX5B2DTPKCjbiujwNK0iZNh4sruCgUc48XLYJ3qvO7w80 EYzBx1MXYDPaaOnGXkPJR9oxChT5uIssVSyRRcXbB3LxepIPHKM9p1XOuP/+iT4qA73G SU3Oekgt4VBEeeLW2p4heAm1XzYH14/J1ciraXbS2ek0JzOPZNuJL2BrFsHus+wpeEfq XmJ4sZl8yCGFwFrSSP+30TVaVVcG5DHJwczPWcu+mVkkahJ7ekyLCp5hlKLWCZZJXha/ aO8rdhEdxpmrmwfTxLe5iGcJdaBMZYjhvJF97eSf8DgDC5YNXdFFDlTfAtVacYI+fcuo FUwg==
X-Gm-Message-State: ALoCoQnxGO+gD02nFVq0I9xhbkZndsdLiOJrpECW5MU5K25+KyOLtJjRFQLucID5i9kS0GPumkZ5
MIME-Version: 1.0
X-Received: by 10.68.189.132 with SMTP id gi4mr5077680pbc.57.1390441715747; Wed, 22 Jan 2014 17:48:35 -0800 (PST)
Received: by 10.70.88.203 with HTTP; Wed, 22 Jan 2014 17:48:35 -0800 (PST)
X-Originating-IP: [2001:dc0:a000:4:24ec:c594:e4f3:af0]
In-Reply-To: <01E2D4B2-ECB1-4601-81A2-15C5D59F42EE@nominum.com>
References: <CAD77+gReP-weV3=_hz-rm0KvDbDjkmsZYc0H_rdQ=R9qpcNhJQ@mail.gmail.com> <24696EC9-3CC7-4518-A029-E385F1C987DD@nominum.com> <CAKr6gn35dWXxmDyuaRVzMfzm508-QBGGz3XnxjsokCXMYOm5ow@mail.gmail.com> <01E2D4B2-ECB1-4601-81A2-15C5D59F42EE@nominum.com>
Date: Thu, 23 Jan 2014 11:48:35 +1000
Message-ID: <CAKr6gn2yyhLwPc5O+QWs3LVK-tGWzsrdu=h7m7NDNgJ5Wk6RLg@mail.gmail.com>
From: George Michaelson <ggm@algebras.org>
To: Ted Lemon <ted.lemon@nominum.com>
Content-Type: multipart/alternative; boundary="e89a8ff1cc028c61f404f099701b"
Cc: IPv6 Operations <v6ops@ietf.org>
Subject: Re: [v6ops] v6-only (with NAT64) as default network during a conference?
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, 23 Jan 2014 01:48:41 -0000

A good point, and diluting focus is often not useful. But I do note that
mobile device access is probably the most visible uptake we have now
worldwide, and its somewhat amusing how little visibility that has inside
IETF. I suspect the verizon customer base aside, few of the attendees
realize half or more of the room could have been using V6 on the telephony
radio spectrum, given a chance.

And you do note there are also risks of breakage in '(with some NAT
traversal technology potentially broken).' but I take your main point: the
goal is to test what breaks, and NAT64 is probably the best path to do that
while keeping a useful net.

Aren't the VPN failure modes you mention in the NAT64 case also plausible
examples which will break in a 464XLAT case?


On Thu, Jan 23, 2014 at 11:42 AM, Ted Lemon <ted.lemon@nominum.com> wrote:

> On Jan 22, 2014, at 8:35 PM, George Michaelson <ggm@algebras.org> wrote:
> > naively, it would be lovely if we could do what an RIR has done, and
> secure alternate SIM for use within a limited horizon and price point,
> which will do 64XLAT for those of us who have Android 4.x enabled devices.
>
> I don't think doing 464XLAT is interesting on the IETF network, because it
> looks just like an IPv4 NATTed network to the host (with some NAT traversal
> technology potentially broken).
>
> The point of setting up an IPv6-only network is to discover what breaks,
> and hopefully to get people used to using IPv6, if it mostly doesn't break.
>   The point of enabling NAT64 is that it is more likely to reveal than
> conceal breakage, and additionally makes it possible to actually use the
> network, which is still a bit difficult on the completely v6-only network,
> more's the pity.
>
>