IETF Logo Mail Archive

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

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

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCA7131234; Thu, 21 Feb 2019 13:40:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Level:
X-Spam-Status: No, score=-1.497 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, HTML_MESSAGE=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 Bn50XIVolzc0; Thu, 21 Feb 2019 13:40:37 -0800 (PST)
Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 70C23131233; Thu, 21 Feb 2019 13:40:37 -0800 (PST)
Received: by mail-ot1-x332.google.com with SMTP id i5so86421oto.9; Thu, 21 Feb 2019 13:40:37 -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; bh=HXBZ+Ym3uauIdzOkh+5/+UuurFKIYsOXlf7ys7Xmeio=; b=G6zmiLedu1R98xH/VqwrWMZeQmGe2rwVeZVocd7pqq8OuywLg0TptCfA1T/GeNhTD8 ErLVgRY7/GyHvjnCzTSD/Q1s7hE3O9f7sRigPbO9IuUvzS4H8YqcpllbmE/MEoxbYeIl ZYNl1RQfSNtQKs48qTcco8ryhTwmf5THak81/ih8bo4HSCm4fbp9XkYvkXNVaDnd10U2 K0HbsvXDzrAgdXHcA5LkoMN18UucMhzKWqGuCLOYWUf4kIrk0G+9SNyQs83mGgLv2Ds4 g5NJ5ZSgYYXkhA6SHB/b1Yk0wr8YJi2wxfnkYhZlNV35l2eTVdA2ovsrBqKrIeRBPZPF y0zw==
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; bh=HXBZ+Ym3uauIdzOkh+5/+UuurFKIYsOXlf7ys7Xmeio=; b=VK+37FfzU830u42iZNBcIT+R0Zk7RbX/3OsfjKgnynpx5tGe+JQYuzA7fk7eb6Ez28 MPBXti7H89pzoAQRZZxCpV5I46ObWFUoCDrcMgdOcbgvIHHM0SgcBbh5QIMfnzNMNRaf d60Vk84w4ZXAPnJYFbDe183cPs1vy+apz/gc1P1fuKro7mlqDOGW7mMTqy1+6Q79HBNC u1qVCHqeg1yFsLxWHk6Frsq30Rm+LGIhfp2y4xQ8hpw7HgNiROH63FSAovbivL2yJLJ6 yoPI3s3yLt0SY8Bbp+IrZmSbPLkOo1o0PnHXqdmyXlPYr22oJadfLRAZuQVF3XEY5kDt q84g==
X-Gm-Message-State: AHQUAuYmyBIlosYhnJxR2WFERTRK4oEFYFYuIshBTMcHhMXUW87U7GkN /bpzC8HYf0NVWzMY2xi7JNMzjNhU/Xfp9oxaKqg=
X-Google-Smtp-Source: AHgI3IZrwk+EnzYfYK75h5MIqqmA1/6EeXdFRXQxNZQIXgTWAQ1ZFGnfNBeFS0hwf1B50N/lAaOBScRZl21dQcV0VVE=
X-Received: by 2002:a9d:6394:: with SMTP id w20mr551234otk.72.1550785236493; Thu, 21 Feb 2019 13:40:36 -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>
In-Reply-To: <20190221073530.GT71606@Space.Net>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Fri, 22 Feb 2019 08:40:24 +1100
Message-ID: <CAO42Z2wmB2W52b4MZ2h9sW5E9cQKm-HRjyf--q8C26jezS7LXQ@mail.gmail.com>
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: multipart/alternative; boundary="00000000000024eaa505826e53cd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Nwv4400GPg_shg1rnYJebstAkik>
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Feb 2019 21:40:39 -0000

On Thu., 21 Feb. 2019, 18:36 Gert Doering, <gert@space.net> wrote:

> Hi,
>
> On Thu, Feb 21, 2019 at 08:43:21AM +0900, Lorenzo Colitti wrote:
> > Because the advantages are for network operators have corresponding
> > disadvantages for application developers and thus for users. Application
> > complexity and brittleness due to NAT traversal. Battery impact of NAT
> > keepalives. Higher-latency due to relaying and rendezvous. And so on.
>
> NPTv6 does not need state, so no keepalives and battery impact.
>
> 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).

Being forced to use a client-server communications model is like going to a
birthday party and having everybody have to conduct all of their
conversations via the birthday girl or boy, rather than directly with any
of the other attendees.

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?

Regards,
Mark.


and everything that
> doesn't care about embedded IP addresses will nicely work throug NPTv6.
>
> 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
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

v2.23.0 | Report a Bug | By Email