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

Philip Homburg <> Wed, 14 October 2020 12:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 04B1E3A098A; Wed, 14 Oct 2020 05:15:48 -0700 (PDT)
X-Quarantine-ID: <H1lINj8Te86O>
X-Virus-Scanned: amavisd-new at
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc"
X-Spam-Flag: NO
X-Spam-Score: -1.624
X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.274, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H1lINj8Te86O; Wed, 14 Oct 2020 05:15:46 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id 7CA3F3A0989; Wed, 14 Oct 2020 05:15:44 -0700 (PDT)
Received: from (localhost [::ffff:]) by with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kSfgy-0000ImC; Wed, 14 Oct 2020 14:15:40 +0200
Message-Id: <>
Cc: 6man <>, dhcwg <>
From: Philip Homburg <>
References: <> <>
In-reply-to: Your message of "Tue, 13 Oct 2020 18:08:19 +0200 ." <>
Date: Wed, 14 Oct 2020 14:15:40 +0200
Archived-At: <>
Subject: Re: [dhcwg] [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: Wed, 14 Oct 2020 12:15:48 -0000

> [if - Theres a couple of problems that this requirement is trying
> to address:
> 1, A misbehaving client (accidentally or otherwise) 2, The volume
> of traffic being forwarded by the relay consumes the available
> bandwidth meaning that DHCP configuration cant complete
> In both cases, the client cant be relied on to solve the problem]

I wonder if the problem can be stated in a more general way.

It seems to me that router should only forward a packet back to the link it
came from when it got the packet directly from a host.

I.e., a host may send a packet to a default router when the best next hop
happens to be different router on the same link. A host may also send a
packet to a default router when the host doesn't know that the destination
is on-link (on NBMA links for example).

In contrast, routers can be relied on to send packet to the correct next hop.
If they don't, then there is something inconsistent in the routing information.
Routers don't react to redirect ICMPs, so this inconsistency could waste a
lot of bandwidth.

One option is to only forward a packet back to the same link if we can also
send a redirect ICMP (ignoring rate limiting). I.e., Section 8.2 of RFC 4861
(Neighbor Discovery) describes that a redirect ICMP can be send if
"the Source Address field of the packet identifies a neighbor"

This could be implemented both in the downstream router and in the upstream

I can see two cases where this could go wrong:
1) multi-homed hosts doing something weird. In that case the host should be
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.