[dhcwg] how do routers with DHCPv6 relays learn when they can delete delegated prefixes

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 15 October 2020 00:14 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24E23A117B; Wed, 14 Oct 2020 17:14:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 rhkQ41imgY50; Wed, 14 Oct 2020 17:14:58 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18CB93A117A; Wed, 14 Oct 2020 17:14:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id DF89438980; Wed, 14 Oct 2020 20:20:46 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id a1C3WPs9RqEe; Wed, 14 Oct 2020 20:20:42 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CBBFF3897F; Wed, 14 Oct 2020 20:20:42 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C33BA23C; Wed, 14 Oct 2020 20:14:51 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: dhcwg <dhcwg@ietf.org>, IPv6 List <ipv6@ietf.org>
In-Reply-To: <B6C7D80D-C72C-42D9-A6FE-41A048A1C363@gmail.com>
References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <9C612486-C25D-463F-8FB4-5BAAF9A96AE5@gmx.com> <m1kSfgy-0000ImC@stereo.hq.phicoh.net> <e96bd8b4ad4b42259f71ad3314fe9066@boeing.com> <B6C7D80D-C72C-42D9-A6FE-41A048A1C363@gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 14 Oct 2020 20:14:51 -0400
Message-ID: <10300.1602720891@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/nB69b-iemrTB0_M8f9cSobdTOT4>
Subject: [dhcwg] how do routers with DHCPv6 relays learn when they can delete delegated prefixes
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Oct 2020 00:15:00 -0000

Bob Hinden <bob.hinden@gmail.com> wrote:
    >> On Oct 14, 2020, at 8:55 AM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
    >>
    >> Philip,
    >>
    >>> 2) Multiple downstream routers on a single link where the downstream routers
    >>> also do not speak a routing protocol. I doubt that we need to support
    >>> this configuration.
    >>
    >> That depends on how you define "routing protocol". DHCPv6 PD driven
    >> by IPv6 ND router discovery would in spirit constitute a routing protocol.

    > DHCPv6 PD / IPv6 ND is not a routing protocol.  Routing protocols are
    > things like OSPF, BGP, Babel, ISIS, etc.

I agree.
DHCPv6-PD needs to interact with routing protocols.  We never said how this works.

In the absense of having standardized that, we have hacks that occur in
DHCPv6 Relays that attempt to treat DHCPv6 traffic as if it was a routing
protocol, when it's not.

That's where the origin of this architectureal failure is.
DHCPv6-PD is a critical part of the IPv6 architecture that allows to say, "No NAT66"
if it doesn't work, then the industry will solve it with NAT66.


{I've left v6ops off. Put it back in the CC if you like}

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide