Re: Extending a /64

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> Thu, 12 November 2020 14:06 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 972783A0EDE for <ipv6@ietfa.amsl.com>; Thu, 12 Nov 2020 06:06:21 -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 VREiegRBjhwt for <ipv6@ietfa.amsl.com>; Thu, 12 Nov 2020 06:06:18 -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 B7B353A0EDB for <ipv6@ietf.org>; Thu, 12 Nov 2020 06:06:17 -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 m1kdDEr-0000FUC; Thu, 12 Nov 2020 15:06:13 +0100
Message-Id: <m1kdDEr-0000FUC@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> <m1kdCLG-0000K7C@stereo.hq.phicoh.net> <7F220C93-E1FE-4381-8001-E2C74ADFA48B@employees.org>
In-reply-to: Your message of "Thu, 12 Nov 2020 14:17:40 +0100 ." <7F220C93-E1FE-4381-8001-E2C74ADFA48B@employees.org>
Date: Thu, 12 Nov 2020 15:06:12 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/BZ54hQjY_UxGtzRPUttOjz55rE8>
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 14:06:22 -0000

> > I link flags once a second, then there is something wrong with that link.
> > DAD takes longer than one second.
> 
> DAD isn't triggered on a downstream interface if an upstream
> interface flaps.  Withdrawing the addresses learnt from the upstream
> interface from all downstream interfaces would break all sessions.
> Even for just a 1s link-flap. Implying that using a reachability
> event to withdraw addressing is a poor idea.

To the extent that a link flap is normal, the router can wait with withdrawing
prefixes until the new link is established (or after some timeout).

In just about all contexts a flapping link is considered broken and should
not be used. If local connectivity is desired in the context of a broken 
link then there is ULA. We have enough ULA space that we can use ULA
recursively if desired. 

> Yes, and that's typically how a more advanced transport layer would
> work. Ref MP-TCP.

That's not clear. If a device simultanously connects over IPv4 and IPv6
using MP-TCP then it might be quite expensive for a content provider to
route both flows to the same endpoint. 

The same applies if a device has addresses from different ISPs. If there
are local caches at the ISPs then it is very unlikely that the two flows
meet.

> > 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.
> 
> If a host has an address that has no reachability it has no cost
> to the far end destination that the host tries it. The packet gets
> dropped quickly anyway.

The cost is time. Applications will wait some time for connection to establish
before moving on to the next address.

The other problem here is API support. There is no practical way for an 
application to iterate over all local addresses. Find out all address is an
operating system specific mess.

But it seems that you saying that Fernando's work on renumbering is a waste
of time because applications should just iterate over all addresses.

> In the multi-prefix multi-home case you cannot weed out all "broken"
> addresses.  Some applications also wants to optimize for the best
> path, and that requires using all available paths and measure. And
> if you think about the multi-homing problem you will realise that
> it has overlapping solutions with the renumbering case.

There is no point for applications to try addresses that can't even reach a 
first hop router. 

By and large we have failed to solve the multi-homing problem. However we can
improve the renumbering problem. What we can do at the network level is
weed out bad addresses that don't work at all.