RE: IETF network incremental plan

<ynir.ietf@gmail.com> Thu, 17 November 2016 01:25 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72A712960D for <ietf@ietfa.amsl.com>; Wed, 16 Nov 2016 17:25:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 yzfQiKMFubG9 for <ietf@ietfa.amsl.com>; Wed, 16 Nov 2016 17:25:24 -0800 (PST)
Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C78271293FD for <ietf@ietf.org>; Wed, 16 Nov 2016 17:25:00 -0800 (PST)
Received: by mail-pg0-x230.google.com with SMTP id x23so82437617pgx.1 for <ietf@ietf.org>; Wed, 16 Nov 2016 17:25:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:to:cc:from:subject:date:importance :in-reply-to:references; bh=mK0a9DmOFkf3j4K8agXaZKX0QSBJwp3TOHZhPhCaWb8=; b=S73Cir+7yHdM2DkMQiegnsTD1rfO2+WZhcy8DROCPnCFshzycovzYU9fmrr7LSKBED M37B1pZmzDx2PXlXlYWRjPb758l/WwS6QeXsdkJO6fa4H4Z2HnBDYw+2INQ82EI93KZ2 jGSZQ3Of2iwg6HQ8qJJVUlxxQOCrbmCWmC/TpXu1CsD9VJwwb7h+TSOgj/emsuZVHe0y lWqL99NEuAH+fLnAcXKwj5tOUX93Zos2Tz7gzWq0c38K6967Zp/p9uZPz5BpCN1JlIff JaWp2SJbC+w1lMW7VOkk6uHAWLhGHZF999sQyGYZESFZ8KtHnYb7id5rVYEJ1Bicp3GB VbzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:mime-version:to:cc:from:subject:date :importance:in-reply-to:references; bh=mK0a9DmOFkf3j4K8agXaZKX0QSBJwp3TOHZhPhCaWb8=; b=OAVcQ6vrauUK2XL3qJJnOw2oW49FAsTRjj8L3mfVARUMih+gLBBmJ4bTHRHBVH75Fg q4VRMJCvlsZElvB2chQmJvoYiYXzJkT1x5rzmJzIF3NYnmkwtS/VXCERSqrk/ScpucB8 2Ye6enJP1wGbKvgR1CrpGHBfy8nD9/ggV7KPYuirSCzd333f4HlmnV+Xz7T7y2yHMgZA QSm6Dstp7seC+C5ekbZX/Jeu2W7AaMzmh4GR10Nx4RJf8E3SAlKA5MOpUE5CRtJ9XPSR /cag5jtkp59tn78eCxbFVY+ChRE1hwHl06q25Tc40i8FTq+TrHqWCWd4XFPJZTj/4Rcq SZNw==
X-Gm-Message-State: ABUngvdmeyv8fQ6jkZ/3234ZzQIYhhevvYeoZl0gGf7rB0WMrKdAdkykURwNb6d6tvq7eA==
X-Received: by 10.99.55.79 with SMTP id g15mr1331987pgn.65.1479345900347; Wed, 16 Nov 2016 17:25:00 -0800 (PST)
Received: from ?IPv6:2001:67c:370:128:71c6:f7f5:cfa0:2e68? ([2001:67c:370:128:71c6:f7f5:cfa0:2e68]) by smtp.gmail.com with ESMTPSA id z9sm629302pfd.29.2016.11.16.17.24.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Nov 2016 17:24:59 -0800 (PST)
Message-ID: <582d06eb.098d620a.b4db8.4495@mx.google.com>
MIME-Version: 1.0
To: Ted Lemon <mellon@fugue.com>, Randy Bush <randy@psg.com>
From: ynir.ietf@gmail.com
Subject: RE: IETF network incremental plan
Date: Thu, 17 Nov 2016 10:24:15 +0900
Importance: normal
X-Priority: 3
In-Reply-To: <CAPt1N1k2m5YLY3wW9Vs61536P+YR3kXQhmveSyfqUhW_bazQ8A@mail.gmail.com>
References: <0C5BCD32-2D2A-42B9-8DEA-A1E1A527A8BB@consulintel.es> <m2zikzq7tg.wl-randy@psg.com> <CAPt1N1k2m5YLY3wW9Vs61536P+YR3kXQhmveSyfqUhW_bazQ8A@mail.gmail.com>
Content-Type: multipart/alternative; boundary="_D8FB735E-9636-431A-97A9-EC4E46B4489B_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/INVLcEuJDbchxsHk-P0PiiRiwvw>
Cc: IETF discussion list <ietf@ietf.org>, Jordi Palet Martinez <jordi.palet@consulintel.es>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Nov 2016 01:25:29 -0000

Interestingly, Windows 10 mobile refuses to join the networks that have no v4 (v6only and nat64).  It is interesting because it does use the IPv6 address in ‘ietf’.

But the top consideration is to get work done.

Yoav

Sent from my Windows 10 phone

From: Ted Lemon
Sent: Thursday, November 17, 2016 9:33
To: Randy Bush
Cc: IETF discussion list; Jordi Palet Martinez
Subject: Re: IETF network incremental plan

At present android apps running on chromebooks do not work over nat64.
  I believe one of our colleagues at Google has filed a bug report on
this, so hopefully it will no longer be an issue in Chicago.

OpenVPN works with nat64, but requires special configuration file
hacking in some cases.

I have no other issues with it.   If it weren't for the fact that my
xmpp app is an Android app, I would be using ietf-nat64 exclusively.

On Thu, Nov 17, 2016 at 9:16 AM, Randy Bush <randy@psg.com> wrote:
> last evening i was carrying a question from the noc team but my position
> in the mic queue was preempted by more important people.
>
> but essentially, before we make tactical decisions we would like to know
> what the purpose and goal of the meeting network is.
>
>   o folk just want to get work done, and the net should bloody well work
>
>   o i want to forward test internet futures: ipv6, auth methods, crypto,
>     ...
>
>   o i have my own stuff i want to test (which may need inbound sessions)
>
>   o network?  what network?
>
> in the nat64 case, are we trying to validate the well-known lists of
> what does not work over nat64, spotify, many vpns, ...?  if it is
> because we think we can modify nat64 to ameliorate the problems, this
> would be brilliant.
>
> if we know what the goals are, we should be able to meet them.  so far,
> the assumption is that
>
>   o the primary goal of the meeting netowrk is for attendees to get work
>     done
>
>   o nats breaking applications and inbound connections would be
>     considered as breakage
>
>   o we do want to support occasional experiments, both non-disruptive
>     and visible (remember the v6-only plenary?)
>
>   o but basically, i just want my mtv
>
> randy, not speaking for anyone else
>