Re: Extending a /64

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> Thu, 12 November 2020 12:16 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 60B343A0769 for <ipv6@ietfa.amsl.com>; Thu, 12 Nov 2020 04:16:17 -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 IXHDepoP63ha for <ipv6@ietfa.amsl.com>; Thu, 12 Nov 2020 04:16:16 -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 B86A43A074E for <ipv6@ietf.org>; Thu, 12 Nov 2020 04:16:15 -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 m1kdBWP-0000I8C; Thu, 12 Nov 2020 13:16:13 +0100
Message-Id: <m1kdBWP-0000I8C@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>
In-reply-to: Your message of "Thu, 12 Nov 2020 13:04:16 +0100 (CET) ." <alpine.DEB.2.20.2011121301300.15604@uplift.swm.pp.se>
Date: Thu, 12 Nov 2020 13:16:13 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/yhJaJZnFr3Mo7AC78UR038HTAUQ>
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 12:16:17 -0000

>If we say the link type is "point to point" and that's the only 
>definition, it'd be applicable to PPP(oE), GTP, the 
>point-to-point-ethernet proposal, possibly some other deployment model 
>where it can be guaranteed that there is only a single recipient of 
>packets. Other tunnel types also comes to mind.
>
>It isn't hard to imagine other media types being designed with this in 
>mind going forward...

In my opinion if we do anything standards track, we have include protocol
elements and requirements that allow a downstream router to verify that the
prefix is still valid. I.e., in my opinion we need to move away from
lifetimes, and link state is a signal but might be an unreliable signal.

So just like ND has NUD to verify that a neighbor is still there, we need
something to verify that prefix is still there. Ideally we can extend that
to SLAAC and DHCP PD and have a model where changes in an upstream link
can propagate downstream realiably.

Real point to point protocols (such as ppp) are in some sense 'easy' in that
you know there is only one other party at the other end. Point-to-point
ethernet is a lot more complex. It would be nice to support point-to-point
ethernet but it might require quite a bit of work to get all corner cases
right.