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

Michael Richardson <> Thu, 15 October 2020 00:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DCA973A1176; Wed, 14 Oct 2020 17:09:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BgV3DRqSis_Q; Wed, 14 Oct 2020 17:09:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9961F3A1173; Wed, 14 Oct 2020 17:09:02 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7200838980; Wed, 14 Oct 2020 20:14:51 -0400 (EDT)
Received: from ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id GFWW73nyxZWQ; Wed, 14 Oct 2020 20:14:47 -0400 (EDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 9C17B3897F; Wed, 14 Oct 2020 20:14:47 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 967316A5; Wed, 14 Oct 2020 20:08:56 -0400 (EDT)
From: Michael Richardson <>
To: "Templin \(US\)\, Fred L" <>
cc: "ianfarrer\" <>, Jen Linkova <>, dhcwg <>, v6ops list <>, 6man <>
In-Reply-To: <>
References: <> <10487.1602608586@localhost> <> <19627.1602701863@localhost> <>
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: <>
Subject: Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Oct 2020 00:09:06 -0000

Templin (US), Fred L <> 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   [
]        |   ruby on rails    [

Michael Richardson <>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide