Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 15 October 2020 00:09 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 DCA973A1176; Wed, 14 Oct 2020 17:09:05 -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 BgV3DRqSis_Q; Wed, 14 Oct 2020 17:09:04 -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 9961F3A1173; Wed, 14 Oct 2020 17:09:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 7200838980; Wed, 14 Oct 2020 20:14:51 -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 GFWW73nyxZWQ; Wed, 14 Oct 2020 20:14:47 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9C17B3897F; Wed, 14 Oct 2020 20:14:47 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 967316A5; Wed, 14 Oct 2020 20:08:56 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Templin \(US\)\, Fred L" <Fred.L.Templin@boeing.com>
cc: "ianfarrer\@gmx.com" <ianfarrer@gmx.com>, Jen Linkova <furry13@gmail.com>, dhcwg <dhcwg@ietf.org>, v6ops list <v6ops@ietf.org>, 6man <ipv6@ietf.org>
In-Reply-To: <1b34b9bec59e4a00af8b9d8f182d23ff@boeing.com>
References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <10487.1602608586@localhost> <378d3420690246bbae253fb15be8c9a7@boeing.com> <19627.1602701863@localhost> <1b34b9bec59e4a00af8b9d8f182d23ff@boeing.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:08:56 -0400
Message-ID: <8825.1602720536@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/V2L3Mu9-BFD78tqEU9HR3_K0Esw>
Subject: Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
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:09:06 -0000

Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
    >> Can you explain how such a device would normally work for a client device
    >> A,B,C,D doing DHCPv6-PD through it?

    > Sure. A sends a DHCPv6 Solicit using its IPv6 link-local address as the source,
    > and its L2 address as the link-layer source. The proxy converts the link-layer
    > source to its own L2 address when forwarding the DHCPv6 solicit onto the
    > upstream link. When the DHCPv6 Reply comes back, the IPv6 destination is
    > that of client A, but the link-layer destination is the L2 address of the proxy.
    > The proxy then converts the L2 destination to the address of client A and
    > forwards it on to the client.

But, how does the proxy know how to forward the prefix that A gets on to A?

The router, having seen A's L2 address on the DHCPv6-PD, and/or having done a
ND on A and receiving L2's address, will punt the traffic to the proxy.
Wouldn't the proxy have to observe the DHCPv6-PDs to know what prefixes are
being delegated?
I didn't think that was a thing.  I think that it just doesn't work.

If it is a thing, then the Proxy will have an L3 route for the prefix that
was delegated so that it can forward traffic from R on to A.

    >> And is the failure one where the router "R" fails to drop traffic it should,
    >> one where the router "R" drops traffic that it shouldn't?

    > I was thinking more along the lines of the latter; if the only way that A has
    > for talking to B, C, D, etc. is by going through R, it wouldn't work if R was
    > unconditionally dropping everything.

If A and B are behind the same Proxy, and each has a prefix delegated to them, and
they have to go all the way to R to get traffic forwarded because they see
R's RAs, not ones that the Proxy has made up, then indeed, R would see the
Proxy's L2 address as src/dst, and it should drop traffic.

But, I would claim that the Proxy should have seen the traffic to R,
intercepted it, and used it's routing table to get the Prefix-A/Prefix-B traffic to B.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


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