Re: Extending a /64

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> Thu, 12 November 2020 13:08 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.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 71A273A0A1F for <ipv6@ietfa.amsl.com>; Thu, 12 Nov 2020 05:08:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.622
X-Spam-Level:
X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
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 xAbwkKMZaKFy for <ipv6@ietfa.amsl.com>; Thu, 12 Nov 2020 05:08:55 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A1BC3A09FC for <ipv6@ietf.org>; Thu, 12 Nov 2020 05:08:54 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kdCLG-0000K7C; Thu, 12 Nov 2020 14:08:46 +0100
Message-Id: <m1kdCLG-0000K7C@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Subject: Re: Extending a /64
From: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <005ECBB3-088B-4363-BB53-8D4AD25CA3D2@employees.org> <b468124f-f85b-7e20-a354-c6b7eaba3447@mccallumwhyman.com> <20593.1604972743@localhost> <CAKr6gn0tedRz4iBu49Lrw5qMCdXWPcg-66UAOfHeJ_ZUeq8U4g@mail.gmail.com> <CABNhwV2c_qaQGY2J62LDh=EZYHo5poYNF_Asf908ofR3wfmW1g@mail.gmail.com> <CABNhwV3wgdOUKqOyqJ4bTvVv4PKq81anYCxASOTCEMg3T84zig@mail.gmail.com> <CAL9jLaaDYrXVTGQeWh4aAc-qUVCoxRNokwANpQhuZ4OGdpySMw@mail.gmail.com> <46a202df-bae8-626b-042a-72adc3d31fcc@gmail.com> <CABNhwV0eRYx9jaygAaZ=KZ45zz-X3+Un17Oi8gv2wzf2-HzXMA@mail.gmail.com> <CABNhwV3cYvdssqK8EJ+_goH5_tLi0vm_Dy5M4bj+-Mp_yVaReg@mail.gmail.com> <m1kdANg-0000IEC@stereo.hq.phicoh.net> <alpine.DEB.2.20.2011121301300.15604@uplift.swm.pp.se> <m1kdBWP-0000I8C@stereo.hq.phicoh.net> <0A0C9446-A4AC-43B8-8383-87A9908C239A@employees.org>
In-reply-to: Your message of "Thu, 12 Nov 2020 13:31:41 +0100 ." <0A0C9446-A4AC-43B8-8383-87A9908C239A@employees.org>
Date: Thu, 12 Nov 2020 14:08:44 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/sxKkWWSzvjumGIxMZ2EnA1wr_R4>
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, 12 Nov 2020 13:08:57 -0000

> Agree with regards to lifetimes.  Addressing != Routing.  You
> shouldn't use a change in reachability to renumber your network.
> Imagine what happens if that link flaps once a second.

As a consumer, by and large Addressing = Routing. If I move to a different
ISP, my address(es) will change. If I take my devices from home to work
and back, address will change. If my phone connects to wifi then typically
it drops the mobile connection and addresses change. If I multi-home I 
will have two (or more) set of addresses, each tied to a specific uplink.

So by and large, for a consumer if routing changes, addressing also changes.

I link flags once a second, then there is something wrong with that link.
DAD takes longer than one second. 

I'm not saying that address should change when a link drops and gets
re-established. I'm saying that from a software point of view, if a link
drops, the software has to be prepared to receive new addresses when the
link is re-established.

If take Fernando's example in renumbering, even equipment permanent installed
in a datacenter may see a link getting moved from one vlan to another.

> The reachability check verifies that the next-hop router has a
> forwarding entry for our route.  It does not guarantee anything
> else.  e.g. in a multi-prefix multi-homed network, the host is the
> only entity that can verify end to end reachability, and it has to
> do it by probing (with all combinations of SA/DA).  The host stack
> must treat addresses as candidates, where all have potential
> different reachability.  Therefore, having stale addresses doesn't
> so much matter.

This kind of probing is extremely tricky. The easiest way to do happy eyeballs
is to just set up parallel connections to every possible address. Hosts have
more than enough resources to do that.

This was quickly rejected by content providers who don't want to see the
number of connects double. Instead happy eyeballs tries IPv6 first and only
tries IPv4 after some time. 

For this reason, it is important to weed out broken addresses locally. If
we can't use a shotgun approach to try all addresses at once, then we have
to void trying the ones that don't work anyhow.