Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

Mark Smith <markzzzsmith@gmail.com> Thu, 21 February 2019 23:22 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFF11312BF; Thu, 21 Feb 2019 15:22:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ZWeXmJrM1NuF; Thu, 21 Feb 2019 15:22:26 -0800 (PST)
Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 73C271312A0; Thu, 21 Feb 2019 15:22:26 -0800 (PST)
Received: by mail-oi1-x236.google.com with SMTP id w66so312198oia.4; Thu, 21 Feb 2019 15:22:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ChN/gHDVJEGm/TymHMIFv609NfvHnFRBBdxGX65VUzU=; b=fcQ3H2YScQjg90uS0pP2o5uhrnYkhIBdTXtoGAZvgvYh7WgLRKCGwd2uiMsmbmp0Kx vuHfr75QP+i7naLOLMGBPDEv56oooBbGiR4/zIlMyRl+n+rWad2sXtFjSJSNzhCUc/PJ rFaS9QFELc9LXC+HItozpMSi9YEPV5IVv7Vt0ukczr0rWnm01Wbb14NZgDLM8LDMzHan GK2xF4tPC0a1DJQvappOG8FxEdsrL9HRP6T/zDTpk5NmHG3JVWh5ZSZrc8WwMjkjS3/j jn9Qspu2ploEgUyBlHp24LsLW2nfTvZ4N452GbMJckfbE9qW2rCLAU6hu8Mm1eQsVOaP nSqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ChN/gHDVJEGm/TymHMIFv609NfvHnFRBBdxGX65VUzU=; b=kZ0pB+A5ScbM7Zvuew+Fk2JdIczX4uW1ELd7ORtgXJ2+bdtwQ21ybLrqDQGlMA17fr u4y8agJqVytzTRYBA6CPH6rZF+gc9aeSOsSDlVeRiNKYXgcdOcf9n37gVdFWjJhtf+fH gdoAUyWZBR60O+cFOxgZ14LPDz3qHHH7+uY/k7EKQbkNoFkdu1qSrCio8vmqaqqXcx9j 7+KmkYZHQtK0jj+MszmTZ0cAo5/QG0lKz1VGVHcHW9Ma57fBLINnIHbgTqDOrxNDaWaq dvhP7RnnqQDAdY8J+T6WIAUAAfWc6AMxFV95/l3Yd0r/X8KcIyBimXnFxmPLCdNIP6Gr 4qrA==
X-Gm-Message-State: AHQUAubcbUmrjwCaDHYF4ZdEm24Kw9oklVEPPfIN7y0PzT4BmRYO3w3r mHed7ILixqwJwGQK2R3Mqfj214K1zFPkWTIxrDo=
X-Google-Smtp-Source: AHgI3IaEMPHrGqwi7pT+6F1aRMnzcKE3Rmjeuyhc+oL6II2Rt6fNWFUUunfyuwXV6zGCvrOEJqJaQyBoLRBxwXahFTo=
X-Received: by 2002:aca:ed06:: with SMTP id l6mr695987oih.7.1550791345209; Thu, 21 Feb 2019 15:22:25 -0800 (PST)
MIME-Version: 1.0
References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <B6E2EC33-EEAF-40D0-AFCC-BDAFA9134ACD@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <CAKD1Yr0HBG+rhyFWg9zh0t3mW486Mjx9umjn+CRqAZg4z9r0dg@mail.gmail.com> <20190221073530.GT71606@Space.Net> <CAO42Z2wmB2W52b4MZ2h9sW5E9cQKm-HRjyf--q8C26jezS7LXQ@mail.gmail.com> <20190221215302.GU71606@Space.Net>
In-Reply-To: <20190221215302.GU71606@Space.Net>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Fri, 22 Feb 2019 10:21:58 +1100
Message-ID: <CAO42Z2xiB+7c7_0SGJJ4fTqrt_z+eu29_dGLXzrbt-79JZphYA@mail.gmail.com>
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
To: Gert Doering <gert@space.net>
Cc: Lorenzo Colitti <lorenzo@google.com>, "Manfredi, Albert E" <albert.e.manfredi@boeing.com>, IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/SaD-_ZrBsGz6BhWHox2-QWmEBdE>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2019 23:22:32 -0000

On Fri, 22 Feb 2019 at 08:53, Gert Doering <gert@space.net> wrote:
>
> Hi,
>
> On Fri, Feb 22, 2019 at 08:40:24AM +1100, Mark Smith wrote:
> > > Applications today seem to be all "HTTP(S)" or "QUIC", and they all had to
> > > learn how to deal with NAPT.  New protocols that embed IP addresses are
> > > killed by IPv4 NAPT anyway, so that ship has sailed -
> >
> > Getting it back in IPv6 is one of the things I hope we can get.
> >
> > That's because applications that would be best performing, most robust and
> > more secure with a peer-to-peer communications model are forced to adopt an
> > absolute client-server model (where the server is a much more likely
> > performance bottleneck, the server becomes a SPOF for all clients using it
> > at the time, and the server is a natural interception point for a malicious
> > server operator).
>
> Have you looked out there recently?  None of the big actors in the market
> seem to have any particular interest in moving away from a "we are the cloud
> content players, you are just visiting clients" model.
>

Generally it's in their business interests not to.

However, just like everybody else, they don't have a choice anyway,
even if they wanted to with IPv4 because of NAT.

Still, there are lots of little actors, and a peer-to-peer model can
allow them to scale their application without having to spend massive
amounts on server infrastructure (physical or virtual.)

> (The gaming industry has, to some extent, but that doesn't seem to be
> a really strong driver)
>

Something significant happened in that regard recently.

"IPv6 on Xbox One"
https://support.xbox.com/en-US/xbox-one/networking/ipv6-on-xbox-one

"And—most useful for Xbox—the expansion removes the need for Network
Address Translation (NAT), which can interfere with multiplayer gaming
and chat over IPv4 networks."

"..., for the best possible experience, we recommend enabling IPv6 on
your network."

> [..]
> > Another analogy to show the significance is that with NAT in the telephone
> > network, it wouldn't be possible for me to give you this phone's number to
> > call me. Would any of us accept that constraint on the usability of our
> > phones?
>
> When did you do the last phone call on your mobile tablet-like computer
> thingie?

Sunday (and I need to get back to my Uncle since). Previous weeks a
number of them organising a trip and updating expired credit card
number details.

I'll observe that you've still got your phone number in your email
signature below, so being able to convey your globally unique phone
number and receive calls to it isn't yet obsolete.

Regards,
Mark.

>
> Gert Doering
>         -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
> Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279