Re: IETF network incremental plan

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Thu, 17 November 2016 01:40 UTC

Return-Path: <prvs=112957b6f1=jordi.palet@consulintel.es>
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 7DFB21295F3 for <ietf@ietfa.amsl.com>; Wed, 16 Nov 2016 17:40:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102
X-Spam-Level:
X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es
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 POygkk97sp8l for <ietf@ietfa.amsl.com>; Wed, 16 Nov 2016 17:40:13 -0800 (PST)
Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1EAA129516 for <ietf@ietf.org>; Wed, 16 Nov 2016 17:40:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1479346809; x=1479951609; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=5WPfnT0Kk39sSdR9DDxFoFQZv JVM35DgQa8FuHrn6a0=; b=tCmr7RSNqkTXiNn6ixu/P67FARRTSQ1QHon8UcImw V4SLcrqRSEaHMkU6MNwCoAxwwp8fFPdWOh0wIs57eY5uzZ8xHdj+zAoCVI8mmB1V hruHVQPURMUh54Xz07XO4meWmMPeiyuQ3Cou7r+YBJEZAmFzLFcAkxHDVi4LLvvX KU=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=RCc7T6S9PAii+L2XTYUgJDdSzti4gJsmKGchlvUXiR6z7qnIq0R5t/b8gGKR 1T8q8s9TAhjshS1zT6tXAONS5DrhfElrVUAHcTjufL6zDye1Q2KczCqCC PQgE6ZVUnTi+/y6MlsEQgfxdNnBUkWL+g2xQlo0YlBuyyM39dJTgDM=;
X-MDAV-Processed: mail.consulintel.es, Thu, 17 Nov 2016 02:40:08 +0100
X-Spam-Processed: mail.consulintel.es, Thu, 17 Nov 2016 02:40:04 +0100
Received: from [31.133.140.36] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005226974.msg for <ietf@ietf.org>; Thu, 17 Nov 2016 02:39:27 +0100
X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0)
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:161117:md50005226974::blYCz18N8WIka19t:00000LBY
X-MDRemoteIP: 31.133.140.36
X-Return-Path: prvs=112957b6f1=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ietf@ietf.org
User-Agent: Microsoft-MacOutlook/f.1b.0.161010
Date: Thu, 17 Nov 2016 10:39:17 +0900
Subject: Re: IETF network incremental plan
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: IETF discussion list <ietf@ietf.org>
Message-ID: <BC620D63-6274-4D62-BCE4-80F3F13B1C66@consulintel.es>
Thread-Topic: IETF network incremental plan
References: <0C5BCD32-2D2A-42B9-8DEA-A1E1A527A8BB@consulintel.es> <m2zikzq7tg.wl-randy@psg.com> <CAPt1N1k2m5YLY3wW9Vs61536P+YR3kXQhmveSyfqUhW_bazQ8A@mail.gmail.com> <582d06eb.098d620a.b4db8.4495@mx.google.com>
In-Reply-To: <582d06eb.098d620a.b4db8.4495@mx.google.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/NduzcpJekC4trJN2VMk5Law0wiQ>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: jordi.palet@consulintel.es
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:40:14 -0000

That’s why at the time being, I’m insisting in looking into the real world:

The real world expects that we have dual stack (private IPv4 + GUA IPv6) in the LANs.

What we need to make sure is that the “access” being IPv6 only, as many ISPs runout of IPv4, is workable by means of a translation in the first hop router (what it will be the CE/CPE in a residential, or SOHO router in an SME, etc.).

Regards,
Jordi


-----Mensaje original-----
De: <ynir.ietf@gmail.com>
Responder a: <ynir.ietf@gmail.com>
Fecha: jueves, 17 de noviembre de 2016, 10:24
Para: Ted Lemon <mellon@fugue.com>, Randy Bush <randy@psg.com>
CC: IETF discussion list <ietf@ietf.org>, Jordi Palet Martinez <jordi.palet@consulintel.es>
Asunto: RE: IETF network incremental plan

    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 <mailto:mellon@fugue.com>
    Sent: Thursday, November 17, 2016 9:33
    To: Randy Bush <mailto:randy@psg.com>
    Cc: IETF discussion list <mailto:ietf@ietf.org>; Jordi Palet Martinez <mailto:jordi.palet@consulintel.es>
    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
    > 
     
     



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.