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

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.

Thanks - Fred

> -----Original Message-----
> From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Philip Homburg
> Sent: Wednesday, October 14, 2020 5:16 AM
> To: v6ops@ietf.org
> Cc: dhcwg <dhcwg@ietf.org>; 6man <ipv6@ietf.org>
> Subject: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-
> requirements
> 
> This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and
> know that the content is safe.
> 
> 
> > [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
> router.
> 
> I can see two cases where this could go wrong:
> 1) multi-homed hosts doing something weird. In that case the host should be
>    fixed.
> 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.
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg